Thread: RE: [GD-General] Scripting Systems
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
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: 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: 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: 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: 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 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 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: 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: 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: <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 20:05:56
|
> 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 This catches assignments at run-time though, not at compile time, correct? Brian |
|
From: <cas...@ya...> - 2004-02-01 20:59:07
|
Brian Hook wrote: >>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 > > This catches assignments at run-time though, not at compile time, > correct? ups, should read mails more carefully! yes, that catches errors at run time only. It's not possible to do that at compile time without fully redesigning the language. However, that allows you to catch errors earlier, and provides a descriptive error message to let you know what's going on. ie. If you use 'healht' instead of 'health' in your 'weapon_hit' function, at runtime you wouldn't know why can't you kill your target, but with the newindex metamethod those errors would show up as soon as the offending code is executed. In my experience (that's not much :D), this kind of runtime checks and a proper test suite can be really helpful. -- Ignacio Castaño cas...@ya... |
|
From: Brian H. <ho...@py...> - 2004-02-02 00:55:52
|
> ie. If you use 'healht' instead of 'health' in your 'weapon_hit' > function, at runtime you wouldn't know why can't you kill your > target, but with the newindex metamethod those errors would show up > as soon as the offending code is executed. Yes, I agree, and at the very least I should add that. I'm also going to add the "read only" facility that Roberto talks about in his book using a similar method. Brian |
|
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: 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 |
×
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