gamedevlists-general Mailing List for gamedev (Page 24)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general — List for discussing general game development issues
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(28) |
Nov
(13) |
Dec
(168) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(51) |
Feb
(16) |
Mar
(29) |
Apr
(3) |
May
(24) |
Jun
(25) |
Jul
(43) |
Aug
(18) |
Sep
(41) |
Oct
(16) |
Nov
(37) |
Dec
(208) |
| 2003 |
Jan
(82) |
Feb
(89) |
Mar
(54) |
Apr
(75) |
May
(78) |
Jun
(141) |
Jul
(47) |
Aug
(7) |
Sep
(3) |
Oct
(16) |
Nov
(50) |
Dec
(213) |
| 2004 |
Jan
(76) |
Feb
(76) |
Mar
(23) |
Apr
(30) |
May
(14) |
Jun
(37) |
Jul
(64) |
Aug
(29) |
Sep
(25) |
Oct
(26) |
Nov
(1) |
Dec
(10) |
| 2005 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
|
May
(11) |
Jun
|
Jul
(39) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
| 2006 |
Jan
(24) |
Feb
(18) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
(14) |
Aug
(29) |
Sep
(2) |
Oct
(5) |
Nov
(4) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(9) |
Oct
(5) |
Nov
(4) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(34) |
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <cas...@ya...> - 2004-02-01 19:40:38
|
Brian Hook wrote:
> It also might be possible to hack Lua so that assignments to
> undeclared variables generate compile time errors, but I'm not
> familiar enough with Lua innards to know if that would be easy or
> difficult.
You can do that without "hacking" lua. This is from the top of my head,
but if you want to follow this direction I can provide a more detailed
explanation, or you may also ask on the lua mailing list for more info.
I think that was a frequently asked question and is probably on the FAQ.
-- Catch access to undeclared properties of the given table.
function CatchUndeclared( table )
local meta = getmetatable( table )
if not meta then
meta = {}
setmetatable( table, meta )
end
meta.__newindex = function (self, key, value)
error( "cannot add '"..tostring(key).."', '"..tostring(value).."' to
protected table" )
end
end
Whis this function you can protect the given table, so that no new keys
can be added to it:
table = {
key1 = 1
}
table.key2 = 2
CatchUndeclared( table )
table.key1 = 2
table.key2 = 3
table.key3 = 4 -- this is not valid!
This also applies to the global table:
CatchUndeclared( _G )
table = {}
newtable = {} -- this is not valid!
Hope that helps.
--
Ignacio Castaño
cas...@ya...
|
|
From: Brian H. <ho...@py...> - 2004-02-01 18:17:42
|
> would need is a way to tell static from dynamic objects. So some > objects are instances of classes, and hence cannot have their > layout modified in runtime. This would solve some of your typo > problems. Yes. > But the real question is: do you really need that ability (dynamic > modification of object layout) at all? In my case, no. > static correctness checks. Is the side-effect of being able to add > a new member to any object really desirable? For me, no. > Note that I don't intend to criticise Lua; I quite like it. But > perhaps it's not the right tool for the job? (Though it's probably > the least wrong one... ;) This is possible, but as you say, it's also possibly the least wrong one. Any suggestions for a scripting language that is: - fast - allows static type checking but does not require it - easy to embed - well supported/documented (at least as well as Lua) the language TOM, syntactically, is the closest to ideal, but it compiles to C and looks like the development is dead (http://www.gerbil.org/tom). Another is IO (www.iolanguage.com) but it's very new and hasn't been nearly as battle tested as Lua. It also might be possible to hack Lua so that assignments to undeclared variables generate compile time errors, but I'm not familiar enough with Lua innards to know if that would be easy or difficult. Brian |
|
From: Jamie F. <ja...@qu...> - 2004-02-01 15:43:19
|
Well, perhaps the problem is languages which add new variables as soon as you use them. Instead, you want one that forces you to declare new ones explicitly. jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Alen Ladavac Sent: 01 February 2004 16:29 To: gam...@li... Subject: Re: [GD-General] Re: Scripting Systems Oh, right, my mistake. I was thinking of Lua's ability to dynamically add vars/functions to objects, making it protoype-based. Though I don't know how I'd call the opposite of that (class-hierarchy based? - though if I understand Self is both protoype-based, and has class hierarchies :/ ). Anyway, what I was trying to say was that if you are able to dynamically add a variable to an object, then the compiler cannot statically check whether it is supposed to exist or not. What you would need is a way to tell static from dynamic objects. So some objects are instances of classes, and hence cannot have their layout modified in runtime. This would solve some of your typo problems. But the real question is: do you really need that ability (dynamic modification of object layout) at all? As I understand, this feature is part of Lua primarily because it makes the syntax simple while still very powerful (structs, classes, arrays, tables... everything is implemented the same way). But it comes at a cost of static correctness checks. Is the side-effect of being able to add a new member to any object really desireable? Note that I don't intend to criticise Lua; I quite like it. But perhaps it's not the right tool for the job? (Though it's probably the least wrong one... ;) Just my 0.02$ Alen ----- Original Message ----- From: "Brian Hook" <ho...@py...> To: <gam...@li...> Sent: Sunday, February 01, 2004 13:36 Subject: Re: [GD-General] Re: Scripting Systems > you describe. Wanting a language to provide both the flexibility of > dynamic typing and safety of static typing at the same time sounds > a bit strange. You would need a language where some types are > static and some are dynamic. If anybody knows of such, I'd like to > know too. :) Objective-C 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_id=557 |
|
From: Alen L. <ale...@cr...> - 2004-02-01 15:25:22
|
Oh, right, my mistake. I was thinking of Lua's ability to dynamically add vars/functions to objects, making it protoype-based. Though I don't know how I'd call the opposite of that (class-hierarchy based? - though if I understand Self is both protoype-based, and has class hierarchies :/ ). Anyway, what I was trying to say was that if you are able to dynamically add a variable to an object, then the compiler cannot statically check whether it is supposed to exist or not. What you would need is a way to tell static from dynamic objects. So some objects are instances of classes, and hence cannot have their layout modified in runtime. This would solve some of your typo problems. But the real question is: do you really need that ability (dynamic modification of object layout) at all? As I understand, this feature is part of Lua primarily because it makes the syntax simple while still very powerful (structs, classes, arrays, tables... everything is implemented the same way). But it comes at a cost of static correctness checks. Is the side-effect of being able to add a new member to any object really desireable? Note that I don't intend to criticise Lua; I quite like it. But perhaps it's not the right tool for the job? (Though it's probably the least wrong one... ;) Just my 0.02$ Alen ----- Original Message ----- From: "Brian Hook" <ho...@py...> To: <gam...@li...> Sent: Sunday, February 01, 2004 13:36 Subject: Re: [GD-General] Re: Scripting Systems > you describe. Wanting a language to provide both the flexibility of > dynamic typing and safety of static typing at the same time sounds > a bit strange. You would need a language where some types are > static and some are dynamic. If anybody knows of such, I'd like to > know too. :) Objective-C 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 |
|
From: Brian H. <ho...@py...> - 2004-02-01 13:36:37
|
> you describe. Wanting a language to provide both the flexibility of > dynamic typing and safety of static typing at the same time sounds > a bit strange. You would need a language where some types are > static and some are dynamic. If anybody knows of such, I'd like to > know too. :) Objective-C Brian |
|
From: Alen L. <ale...@cr...> - 2004-02-01 09:44:26
|
From: "Brian Hook" <ho...@py...> >They are, but this wasn't really meant to be a "how do I fix this in >Lua" type question, but more of a "do all dynamically typed scripting >languages suffer from similar problems?" question. PMFJI, but I'd say that bare fact that a language is dynamically typed gives you enough rope to hang yourself in the exact ways that you describe. Wanting a language to provide both the flexibility of dynamic typing and safety of static typing at the same time sounds a bit strange. You would need a language where some types are static and some are dynamic. If anybody knows of such, I'd like to know too. :) Alen |
|
From: Brian H. <ho...@py...> - 2004-02-01 04:30:21
|
> Yeah, agreed, you have to be pragmatic. Another way to look at > this is that community/social/marketing attributes of programming > languages are very important -- in many respects more important > than technical aspects. I rant about just that (along with other stuff) on my Web page here: http://www.bookofhook.com/Article/GameDevelopment/TipsforOpenSourceDev elope.html In a nutshell, if you're open sourcing something, then in theory it's because you think other people should use your stuff. So put out the effort to evangelize/educate, and if you don't, don't cry because your project isn't as popular as the others that "aren't as good". Brian |
|
From: Thatcher U. <tu...@tu...> - 2004-02-01 04:06:20
|
On Jan 30, 2004 at 03:50 -0500, Brian Hook wrote: > > Since the NJS implementation scored poorly, that was the only > datapoint I had to go by for SpiderMonkey even though it's an > unrelated codebase. I was taken to task for this assumption > (rightfully so), but at the same time that's effectively asking me to > try out every language and see for myself if it's going to be > effective or not, and I don't have that kind of time. There are > probably 20 or so small languages that are interesting in some fashion > or another (Small, IO, etc.) but which I don't have the time to really > sit down and exhaustively give a "fair" assessment. > > So I put the onus on the implementors if they want people to adopt > their stuff. Yeah, agreed, you have to be pragmatic. Another way to look at this is that community/social/marketing attributes of programming languages are very important -- in many respects more important than technical aspects. -- Thatcher Ulrich http://tulrich.com |
|
From: Donavon K. <kei...@ea...> - 2004-01-31 21:21:04
|
Mono appears to be shaping up nicely. They say they're targeting a 1.0 release in Q2 and 1.2 by the end of the year. At this point most of the effort is in finishing the class libraries -- not really a concern for game devs. So I'd say it's mature enough to begin evaluating but, sure, a commitment at this time would be a gamble. I don't think it would be a *huge* gamble, given that it's open source and that there's a quite a lot of interest in the project. I think it more comes down to whether you can get it to build on your target platform, what the footprint is going to be, etc. With the x86 and PowerPC jitters essentially complete (FWICT), Xbox 1 & 2 and GameCube 1 & 2 seem the most promising. And then there's always the interpreter engine... Even if you can strip it down to the barest essentials, I doubt it's going to be anywhere near as lean as Python much less Lua, and for current generation consoles that's pretty much a deal-killer. I'm more intrigued by the possibility of using C# for downloadable games and not requiring players to also download a 23MB runtime. > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On Behalf Of > Timur Davidenko > Sent: Saturday, January 31, 2004 5:17 AM > To: gam...@li... > Subject: RE: [GD-General] Scripting Systems > > .NET seems to be not portable enough for now, > If you planning that your game will also be available not on PC but on > consoles (And you always have to plan it, if you planning your game to > be successful), .NET if not right choose right now. > Although I seen .NET runtime open source initiative's, it seems kind > risky. > > _____________________ > Timur Davidenko. > Crytek (www.crytek.com) > > -----Original Message----- > From: tweety [mailto:mi...@sy...] > Sent: Thursday, January 29, 2004 10:04 AM > To: gam...@li... > Subject: RE: [GD-General] Scripting Systems > > Has anyone tried using the dotNet framework for doing scripting? As I'm > currently writing a game in c# (small, hobby-like game :D), it seems > natural. It's also quite fast and there is a pretty good debugger for it > (VS.NET). You could also use it with COM interop from C, who knows, > maybe > it's fast enough... > > ---------------------------------- > Peace and love, > Tweety > mi...@sy... - twe...@us... > YahooID: tweety_04_01 > > ________________________________________________________________________ __ > ___________________________ > Disclaimer: > > This message contains confidential information and is intended only for > the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. E-mail transmission cannot be > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. > The sender therefore does not accept liability for any errors or omissions > in the contents of this message, which arise as a result of e-mail > transmission. If verification is required please request a hard-copy > version. Crytek GmbH -http:// www.crytek.com > > > ------------------------------------------------------- > 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 |
|
From: Timur D. <ti...@cr...> - 2004-01-31 12:15:51
|
.NET seems to be not portable enough for now, If you planning that your game will also be available not on PC but on consoles (And you always have to plan it, if you planning your game to be successful), .NET if not right choose right now. Although I seen .NET runtime open source initiative's, it seems kind risky. _____________________ Timur Davidenko. Crytek (www.crytek.com) -----Original Message----- From: tweety [mailto:mi...@sy...]=20 Sent: Thursday, January 29, 2004 10:04 AM To: gam...@li... Subject: RE: [GD-General] Scripting Systems Has anyone tried using the dotNet framework for doing scripting? As I'm currently writing a game in c# (small, hobby-like game :D), it seems natural. It's also quite fast and there is a pretty good debugger for it (VS.NET). You could also use it with COM interop from C, who knows, maybe it's fast enough...=20 ---------------------------------- Peace and love, Tweety mi...@sy... - twe...@us... YahooID: tweety_04_01 ___________________________________________________________________________= __________________________ Disclaimer: This message contains confidential information and is intended only for = the individual named. If you are not the named addressee you should not = disseminate, distribute or copy this e-mail. Please notify the sender = immediately by e-mail if you have received this e-mail by mistake and = delete this e-mail from your system. E-mail transmission cannot be = guaranteed to be secure or error-free as information could be intercepted, = corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. = The sender therefore does not accept liability for any errors or omissions = in the contents of this message, which arise as a result of e-mail = transmission. If verification is required please request a hard-copy = version. Crytek GmbH -http:// www.crytek.com |
|
From: tweety <mi...@sy...> - 2004-01-31 07:10:01
|
Has anyone tried using the dotNet framework for doing scripting? As I'm
currently writing a game in c# (small, hobby-like game :D), it seems
natural. It's also quite fast and there is a pretty good debugger for it
(VS.NET). You could also use it with COM interop from C, who knows, maybe
it's fast enough...
----------------------------------
Peace and love,
Tweety
mi...@sy... - twe...@us...
YahooID: tweety_04_01
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of Brett
Bibby
Sent: January 28, 2004 6:46 PM
To: gam...@li...
Subject: Re: [GD-General] Scripting Systems
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
|
|
From: Brian H. <ho...@py...> - 2004-01-31 02:41:53
|
> Please enlighten my heathen mind: Why not simply compile your > "scripts" into C/C++ .DLLs? The sheer number of them can be daunting. In a lot of cases you're talking about several hundred if not several thousand scripts if you want to be able to dynamically load/reload chunks of code. I actually posed the same question not too long ago (look for the thread "DLLs as game objects"). But other considerations: - scripts now requires real programming, whereas a language like Lua or Python is (in theory) a bit friendlier when doing basic scripting like behaviour, triggers, etc. - security problems since you can't sandbox C++ particularly well > Um, really? Is Lua any easier to write than C? Yes, since there aren't any pointers. Remove memory management, and probably 50% of newbie C mistakes are gone. Get rid of arcane syntax like the whole & vs. * thing, and you get rid of another good chunk. Get rid of "stack" vs "heap" and hey, more problems go away. > 3. The security of a sandbox. > > > Ok, you've got me there, if your primary goal in scripting is to > allow your fanbase to create new content without exposing other > users to a variety of security scenarios, then I suppose you've > found your holy grail. That's a pretty major one, IMO. Not just that, but sandboxing protects your own designers from inadvertently trashing something if they're trying to make an edit on a live world (e.g. in an MMOG). > All that aside, I do believe there are some C-syntax scripting > ideas, Battlefield 1942 uses a "scripting" language that is really > more along the lines of a gameplay balancing dataset. Well, there's the whole data-driven vs. procedural argument, but I don't think we have time to get into THAT one again here... > I'm just not significantly compelled to go beyond dynamic library- > based extendability for the time being. I felt the same way, but for the particular problem domain I'm working in, I specifically need reloadable code, sandboxing and ease of use. Brian |
|
From: Brian H. <ho...@py...> - 2004-01-31 02:35:04
|
> I don't see what's so wrong with Lua's documentation. It has all > the info about the language, up to the next step - how to actually > use it. Well, write -- learning anything strictly from a reference manual isn't exactly the best way to go about it. Sure, everything you need is there, but what could take 5 minutes with proper documentation instead takes several hours through trial and error as you try to sort out what they meant in one sentence. > And I must admit, there are plenty of ways one can use Lua > (just as with C++). Okay, comparing Lua to C++ isn't doing it any favors =3D) > I suppose the recently published book by > Roberto Ierusalimschy (one of the creators of the language) talks > about that. It's quite a good book, it's just bothersome that it took until version 5 for the book to arrive. >> o.foo( y, x, z ) -- oops! >> > > If x and y are of the same type, you wouldn't be able to catch this > in any language. Sure, but if they AREN'T of the same type, you would =3D) > Syntactic errors are easily found by using loadstring/loadfile (I'm > talking about Lua 5.0). Actually doing a preprocess with luac will find the blatant syntax errors, so forcing that as a preprocess then loading strictly the .out files would work as well. > I don't know any other scripting language that has these problems > solved, I guess only the language you write yourself can solve > them... And of the 3rd party languages Lua does the most things > right. Note that I wasn't trying to say that Lua was somehow "bad" -- I still like the language. I was mostly trying to see how others have solved these issues that are rarely talked about. Everyone knows about the advantages of scripting languages and how to load them and how to embed them and all sorts of issues with using them in terms of usability and performance, but I'm surprised at the fairly sparse information or discussion on the pragmatic problems with a dynamically typed scripting language. > You should ask questions like these on the Lua mailing list, I > think the people there are generally very helpful. They are, but this wasn't really meant to be a "how do I fix this in Lua" type question, but more of a "do all dynamically typed scripting languages suffer from similar problems?" question. Brian |
|
From: Brett B. <res...@ga...> - 2004-01-31 02:26:36
|
> Run-time is the only way to do it. Lua is a dynamically typed=20
> language, and since it doesn't even comprehend the idea of user=20
> defined types, "type checking" is kind of a no-op. =20
>=20
> What we'd need is a preprocessor that uses a convention where any=20
> uninitialized element accessed out of a table constructor or=20
> declaration is definitely bad.
>=20
> v =3D { x =3D 0, y =3D 0, z =3D 0 }
> v.zz =3D 3 --<< BZZZT!
>
Idea 1
A hack to be sure, but I could trap the __index error and do some sort =
of "spell checker" against known elements, starting with the locals and =
working my way upward. If it finds a recommended match (within some sort =
of error metric) it changes it and keeps going. If I have a debugger it =
could pop-up with the suggestion and allow me to accept or choose =
another symbol and optionally modify the source for me to correct the =
problem. Without a debugger it could output a log that looks like =
preprocessor logs showing the error, line number, etc. As long as there =
is an option to enable/disable the feature, it would probably fix like =
90% of the errors.
Idea 2
Based upon the concept of automated unit testing, I could load the =
function to compile, generate a unit test for each function, compile and =
load both of them, and run the unit test against it. Failures could do =
something like Idea 1 above and when fixed is written to disk (as an =
obj). This gives you a Lint-like system and since we compile each =
function as an object, incremental build will keep the performance =
acceptable. Plus it has the ability to interactively fix problems.
Anybody tried this? This sounds pretty workable to me.
Brett
|
|
From: Garett B. <gt...@st...> - 2004-01-31 02:01:36
|
Design folks, Ok, sorry to distract you all, but I just don't get it. After reading about Brian's problems with his scripts (and additionally having considered the problem at length without actually implementing any scripting system myself [except for my pitiful attempt at *writing* a scripting system for Deer Hunter 3, which we won't go into here for fear of grave embarrassment to myself]) it seems to me that "scripting" is being used to solve problems that could just as easily be solved by real code. Please enlighten my heathen mind: Why not simply compile your "scripts" into C/C++ .DLLs? These are the arguments I can vaguely recall for scripting, but I just don't think they hold up: 1. You don't have to compile scripts. I mean, ok, yeah, you gotta spend a few seconds on compiling some C/C++ into a .DLL (holy mother of poo!), but that serves a handy purpose: the compiler checks a variety of error and warning conditions that give you immediate feedback before you even try the script. And if it is so difficult to arrange a test case for the script's performance, are you really saving any time by not using a compiled language? 2. Scripting code is easier for designers to write. Um, really? Is Lua any easier to write than C? Ok, it's more verbose, but verbose just means more symbols to remember and use correctly. At work I'm stuck using Visual Basic, and while it is pretty handy for our problem domain (RAD w/ database and native GUI), it also really confuses some of my C++ instincts (and vice-versa). 3. The security of a sandbox. Ok, you've got me there, if your primary goal in scripting is to allow your fanbase to create new content without exposing other users to a variety of security scenarios, then I suppose you've found your holy grail. At the cost of 15x performance of course. I seem to recall the user community (PlanetQuake et al.) doing a pretty good job of filtering through the security of mods, in fact, I don't recall any news of blaster or welchia worms arising from Q2 mods, but you know, whatever keeps your paranoid heart skipping happily along, go for it. Even if it is a huge pain in the ass. All that aside, I do believe there are some C-syntax scripting languages out there these days (http://csl.sourceforge.net/csl.html). In the realm of other ideas, Battlefield 1942 uses a "scripting" language that is really more along the lines of a gameplay balancing dataset. You can code up new vehicles in plain text by combining engines and meshes and various attributes in new and interesting ways, but you can't really change the core gameplay mechanic. I'm just not significantly compelled to go beyond dynamic library-based extendability for the time being. However, I am significantly compelled to find out why the higher minds of my time think otherwise. Please excuse my dear Aunt Sally. Regards, Garett Bass gt...@st... |
|
From: Ivan K. <ik...@ab...> - 2004-01-31 02:00:01
|
As a fan of Lua (can't say that I'm an expert, but I've used it a bit), I felt the need to comment. > 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. I don't see what's so wrong with Lua's documentation. It has all the info about the language, up to the next step - how to actually use it. And I must admit, there are plenty of ways one can use Lua (just as with C++). I suppose the recently published book by Roberto Ierusalimschy (one of the creators of the language) talks about that. So, I've never missed anything in the Lua manual, except a "Tips & tricks" section. That can be found partially in the Lua technical notes and on the lua-users.org site. > 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. True. However, the real power of Lua lies in its ability to create mechanisms. You actually *can* add all sorts of type checks or property access restrictions, if you want. Yes, that's a bit of additional work, and can slow down execution, but you can disable it in final builds. I know Lua could use a standard library with a set of pre-defined mechanisms... hopefully this will happen one day, esp. with the new LuaCheia project. > 1. Accidentally typing object:method() instead of object.method() or > vice versa You could catch this with a type check system. > 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() This goes away after a bit of practice, and getting used to 'think in Lua': if you could write t:insert(...) for any table, this would mean that you have a global propery "insert" inside all tables, which doesn't make much sense. > 3. Typographical/memorization errors: > > function object.foo( x, y, z ) > .... > end > > o.foo( y, x, z ) -- oops! If x and y are of the same type, you wouldn't be able to catch this in any language. > or: > > function client.create() > =09local c =3D { client_name =3D "Default" } > =09return c > end > > c =3D client.create() > c.name =3D "Brian Hook" -- oops! A class + type check system here would help too. > or > > -- oops, forgot the 'then'! > if c.client_name =3D=3D "Brian Hook" > c:doSomething() > end Syntactic errors are easily found by using loadstring/loadfile (I'm talking about Lua 5.0). > 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"... Yes, that's a problem. Although you can call scripts with xpcall and use debug.debug() or your own function as an error handler, I suppose it would be hard to replace the faulting function from inside the handler. But it's probably not impossible to implement an 'edit and continue' feature, in a future Lua version, or even now. > 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.). I don't see how you can use an IDE for embedded scripts, with any language, unless you build it yourself inside your game editor or the game itself. The same for unit tests. > 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) This is a good idea. > 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? Especially difficult?? It's definitely quite easy to save a Lua table into a .lua file... Currently I'm using Lua to create some tools, almost as a standalone language for rapid development, and I run into these problems as well (mostly type checking). I think it's possible to find solutions to them, using the mechanisms the language provides. BTW, Lua 5.0 is definitely an improvement over previous versions, though I suppose it's not easy to switch from 3.2 or 4 to 5, if you already have a working Lua connection and lots of scripts... But switching should be considered when beginning a new project. I don't know any other scripting language that has these problems solved, I guess only the language you write yourself can solve them... And of the 3rd party languages Lua does the most things right. You should ask questions like these on the Lua mailing list, I think the people there are generally very helpful. At least the language authors will consider these issues for future releases... It seems they are paying special attention to the usage of Lua in games. Ivan |
|
From: <cas...@ya...> - 2004-01-31 01:45:37
|
gekido wrote: > www.scintilla.org - built in lua syntax highlighting, api etc > > very slick, open-source, and very easy to create your own API for > function auto-complete etc scite is an excelent editor. However, it doesn't provide all the features that a good IDE would provide, for example, an integrated parser that analizes your code and provides dynamic autocompletion. In lua that would be quite hard, because it doesn't have class declarations. In fact, it doesn't have classes, only tables, and they aren't declared either, so it would be quite hard to provide autocompletion. I think that it would be possible to provide autocompletion, writting an integrated editor in your game (it's really easy if you use scite) and write the code while the game is running. If the object is global, it's easy to inspect it, but if it's local, it becomes much harder... -- Ignacio Castaño cas...@ya... |
|
From: Timur D. <ti...@cr...> - 2004-01-31 01:35:11
|
Lua is wonderful language when used nicely :)
But can stab you in the back for small errors...
I don't think it even possible to find a solution for "missing" members,
After all Lua as most script languages are weak typed, and this benefit
you ease of real-time member modification against rigid but safer C++
strong typing.
Restricting things like v.zz =3D something; just doesn't make sense...
this is a perfectly valid way in LUA to make a new elements in the
table, one of the core functionalities, and if you disable v.zz =3D ...
you will not be able to do v["zz"] =3D .... And so on...
Usually this kind of errors can be easily catched in run-time, reported
to user and can be fixed without even closing the game, (if game support
reloading of scripts)
As for debugging... I never actually even used our build in lua
debugger.. fastly adding log, reloading scripts and seeing what's
happening is usually simpler, and if scripts become so complex that you
have to really debug them, then I guess you'll need to revisit the way
you use Lua, as it very inefficient and error prone (Due to reasons you
mentioned) to do large chunks of code in it.
P.S.
v =3D { x =3D 0, y =3D 0, z =3D 0 } -- This is a code you NEVER want to =
see
inside your frequently executing functions, Lua is fast, but at the
moment GC kicks in you pretty much screwed, don't sure about latest Lua
GC but in previous versions GC time was depended on the amount of
globally allocated lua objects, and for game it can be very large
amount...
You would probably want, to make a special function that will dump lua
stack on every Lua allocation, and try to go and eliminate Any
allocatins which occur when game running normally (without too many game
events occurring).
I managed to get 0 lua allocations when game is just running (when you
not shooting, or doing special things...),
Without doing so , ~50ms stalls every few seconds, can be quite usual..
_____________________
Timur Davidenko.
Crytek (www.crytek.com)
-----Original Message-----
From: Brian Hook [mailto:ho...@py...]=20
Sent: Thursday, January 29, 2004 2:47 AM
To: gam...@li...
Subject: Re: [GD-General] Scripting Systems
> 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.=20
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=20
language, and since it doesn't even comprehend the idea of user=20
defined types, "type checking" is kind of a no-op. =20
What we'd need is a preprocessor that uses a convention where any=20
uninitialized element accessed out of a table constructor or=20
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.=20
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.=20
Yep.
Sounds like we're in the same boat but without a solution =3D|
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
|
|
From: tweety <mi...@sy...> - 2004-01-31 01:02:55
|
Why don't you just save the game before the encounter and, when needed, load it back up? ---------------------------------- Peace and love, Tweety mi...@sy... - twe...@us... YahooID: tweety_04_01 -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of gekido Sent: January 28, 2004 8:02 PM To: gam...@li... Subject: Re: [GD-General] Scripting Systems 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 > > ------------------------------------------------------- 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 |
|
From: <e_a...@ya...> - 2004-01-30 23:49:55
|
Hi, I'm quite surprised nobody pronouce the name of python yet. So here I go : I found Python to be a good scripting language. From what I've been told, the language is cleaner than Lua (I've never used Lua ). There are a lot of tools/site/support anywhere on the web. It supports coroutine, have a lot of useful lib (Zip for instance ). It can be used for other tasks (automated build, HTTP stuff, ... ). Last but not least, the HAP debugger is a remote debugger/IDE. There can be some perf issue on this gen consoles, thought I think some people manage to port it and use it (there are some GC and PS2 Python project on the web), and with the new console gen that is to come, there will be no reason not to use it... Hope it helps Emmanuel --- Brett Bibby <res...@ga...> a écrit : > 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 > Yahoo! Mail: votre e-mail personnel et gratuit qui vous suit partout ! Créez votre adresse à http://mail.yahoo.fr |
|
From: gekido <mi...@ge...> - 2004-01-30 23:07:55
|
> Also, as you said, python has the benefit of many good IDEs that help > you write correct code. I think lua does not have a good IDE, but I > haven't looked for it either. www.scintilla.org - built in lua syntax highlighting, api etc very slick, open-source, and very easy to create your own API for function auto-complete etc cheers mike w www.gekidodesigns.com |
|
From: <cas...@ya...> - 2004-01-30 22:52:11
|
Brian Hook wrote: > Do other languages handle this any better? JavaScript suffers from > the same problems since it is also prototype-based (a la SELF et. > al.). For this kind of problems I would suggest to use test units, to catch the errors without having to play the game. With a scripting language test units are easy to write and you can implement a simple testsuite application to run them all automatically. I would also look at python, I think they may have similar problems. Here is an interview of the Guido van Rossum about strong and weak typing, that might be of interest: http://artima.com/intv/strongweak.html Also, as you said, python has the benefit of many good IDEs that help you write correct code. I think lua does not have a good IDE, but I haven't looked for it either. Hope that helps. -- Ignacio Castaño cas...@ya... |
|
From: Richard <ri...@cc...> - 2004-01-30 21:45:11
|
> From: gam...@li... > [mailto:gam...@li...]On Behalf Of > Brian Hook >=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 We use Python which is not any better. Like yourself and Brett, we can also update things on the fly to make things easier although we don't pause the game under a debugger to do it although I can see how being able to freeze the game state and modify the logic without the state changing in the meantime would make it even easier to=20 rearrange the code to take advantage of the state. If there is an error in one of our scripts I can usually change the script and save it. The game hooks into the Windows and catches the file event and reloads the script replacing the designated elements in the script in their relevant namespaces. If the script was a service that ran and was called on by other game logic, all the objects that call on it would use the new version automatically. If the script was a class that was used by some logic or other, sometimes it is easier to kill the game and to restart it. For the most part however, I can generally just cause a new instance to be created and test that. Depending on what it is an instance of, if use of the functionality related to it in-game creates a new instance everytime, then its pretty straightforward. If not, then some selected statements in the console or the relevant web page can force it to be used and/or can ascertain that the new version no longer has the old problems. If the class changed is used by sub-classes of which there are instances of, it may error when these instances try to use methods on their inherited class (not 100% since it doesn't happen that often). Its a very nice environment to work in. But when I think of it, its not that different from the environment I used to use when I programmed in LPC under MudOS, the only real difference is that we didn't have scripts reloading automatically when the file was changed and that MudOS had no problems (that I remember) with instances that inherited classes which had since been replaced with changed versions. Richard. |
|
From: Brian H. <ho...@py...> - 2004-01-30 20:50:18
|
> 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. JavaScript gets a bit of a bad rap, mostly because it's associated with, say, mouse rollovers. There was a discussion about this on the vworld-tech mailing list, and basically one of the big things, IMO, that's holding back mass adoption of SpiderMonkey is that people just have no idea if it's fast or not. As much as the GLCS is a pile of poo, it's all a lot of people have to go on when it comes to real world performance measurement. When I saw Ruby routinely being outperformed by a factor of 5 to 10 or more, I knew that it probably wasn't going to be practical for my use. Since the NJS implementation scored poorly, that was the only datapoint I had to go by for SpiderMonkey even though it's an unrelated codebase. I was taken to task for this assumption (rightfully so), but at the same time that's effectively asking me to try out every language and see for myself if it's going to be effective or not, and I don't have that kind of time. There are probably 20 or so small languages that are interesting in some fashion or another (Small, IO, etc.) but which I don't have the time to really sit down and exhaustively give a "fair" assessment. So I put the onus on the implementors if they want people to adopt their stuff. And in situations like that, I pretty much fall back to Lua =3D) Brian |
|
From: David B. <d.j...@wa...> - 2004-01-30 20:48:42
|
> 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 > Maybe I am missing something here, but arnt other people recording logs of there user input(or some other critical message path within there simulation). This is very useful in all kinds of similar situations. If these are time stamped, upon discovering a bug and fixing the script cant you have the engine replay the input(which should be fast if you are running the simulation on its own, without graphics etc) to a safe point a few seconds before the problem, pause, upload the changes and continue playing until you find another bug... David |
12 messages has been excluded from this view by a project administrator.
