Thread: RE: [GD-Design] Scripting Engine and C++ Games
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-design
|
From: Tom F. <to...@mu...> - 2002-07-12 11:28:19
|
Python is a good scripting language. It's pretty easy to integrate with C/C++, and some people have gone as far as writing the whole game in Python and just calling C functions for the rendering, or (and I kid you not) inheriting C classes from Python ones, and overriding the slower functions. There was a GDC talk on this (and lots of nice open-source tools) by Humungous Entertainment. We're also thinking of using a lot of Python in our next project(s). Whether we'll go the whole hog and have the game written in Python and calling bits of C, I don't know. But we're definately in favour of having large chunks of it in Python. It's an impressively graceful language. Others have talked in favourable terms about LUA. It's slightly newer than Python, and has a few cuter techniques, but my perception is that the tools support is slightly poorer (simply because it's a newer language), so you need to decide what you need from your language. Tom Forsyth - purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: LordEidi [mailto:lor...@sw...] > Sent: 12 July 2002 12:04 > To: gam...@li... > Subject: [GD-Design] Scripting Engine and C++ Games > > > Hello > > We from SwordLord.com are currently coding for a new game. This game > should contain a scripting engine with the idea to help us to > script many > of the games features instead of hardcode them in c++. Also level > designers could add to the games behaviour like that. (As > more script in > the game as happier I am ;)) > > We are currently in the design and architecture phase of that > scripting > engine and would like to hear comments, suggestions, tips and > read some > good texts on that topic. Especially on the topic of how to knit the > scripting and the c++ part together. How they both interact. > > Has any of you some experience on that topic and could help > us with some > tips or could supply us with a link to a good website or book? > > Thanks in advance, > > LordEidi > SwordLord.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Gadgets, caffeine, t-shirts, fun stuff. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-design mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-design > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=556 > |
|
From: Gareth L. <GL...@cl...> - 2002-07-12 11:32:31
|
Take a look at http://www.drizzle.com/~scottb/gdc/fubi-paper.htm We are using it and are extremly happy with it, thanks Scott ;) Ofcourse you can still write whatever syntax for the laungage you want, or use Lua/Python/Tcl ( Those seem to be the most commonly used ), but Fubi is definitly the way to connect the scripting language up with the game. We even have it working find for member functions and stuff. Very happy indeed. On a personal note, out of the common Lua/Python/Tcl options, I find tcl is the easiest for someone that knows no programming ( i.e. designers ) and Lua is the best for C/C++ coders. ___________________ Regards, Gareth Lewin -----Original Message----- From: LordEidi [mailto:lor...@sw...] Sent: 12 July 2002 12:04 To: gam...@li... Subject: [GD-Design] Scripting Engine and C++ Games Hello We from SwordLord.com are currently coding for a new game. This game should contain a scripting engine with the idea to help us to script many of the games features instead of hardcode them in c++. Also level designers could add to the games behaviour like that. (As more script in the game as happier I am ;)) We are currently in the design and architecture phase of that scripting engine and would like to hear comments, suggestions, tips and read some good texts on that topic. Especially on the topic of how to knit the scripting and the c++ part together. How they both interact. Has any of you some experience on that topic and could help us with some tips or could supply us with a link to a good website or book? Thanks in advance, LordEidi SwordLord.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=556 |
|
From: Stefan B. <sbo...@te...> - 2002-07-12 13:15:15
|
> Take a look at http://www.drizzle.com/~scottb/gdc/fubi-paper.htm > > We are using it and are extremly happy with it, thanks Scott ;) > > Ofcourse you can still write whatever syntax for the laungage you want, or > use Lua/Python/Tcl ( Those seem to be the most commonly used ), but Fubi > is definitly the way to connect the scripting language up with the game. ... iff you are targeting Win32 only ;) You will have to come up with some other mechanism for NGC/PS2, although I suppose you could extract the parameter info from your Win32 exe and use it to generate some sort of tables that you can link into the NGC/PS2 version. But then, you might as well just use SWIG, or even Doxygen to scan your code to generate the export tables. That's what I do :) Oh, and for the record we use LUA. I looked at Python but it seems too heavy and sluggish for scripting our games. But then, I didn't really try using it in anger so it may work better than LUA in practice. LUA seems ok so far and "if it ain't broke..." so I guess I may never find out ;) Cheers, Stef! :) -- Stefan Boberg, R&D Manager - Team17 Software Ltd. bo...@te... |
|
From: Gareth L. <GL...@cl...> - 2002-07-12 13:23:23
|
I talked to our NGC/PS2 people about this kind of stuff, apparently the NGC has some kind of dynamic linking, but not the ps2. Both were just idle discussions, neither were really tested. Note that Fubi works wonders on the xbox, even though it doesn't support dynamic linking, so perhaps you could export stuff on the NGC/PS2 just because gcc happens to support that for other targets. All you really need is a way to get the code segment position of the functions and to work out the name mangling/variable passing stuff. -----Original Message----- From: Stefan Boberg [mailto:sbo...@te...] Sent: 12 July 2002 14:15 To: gam...@li... Subject: RE: [GD-Design] Scripting Engine and C++ Games > Take a look at http://www.drizzle.com/~scottb/gdc/fubi-paper.htm > > We are using it and are extremly happy with it, thanks Scott ;) > > Ofcourse you can still write whatever syntax for the laungage you want, or > use Lua/Python/Tcl ( Those seem to be the most commonly used ), but Fubi > is definitly the way to connect the scripting language up with the game. ... iff you are targeting Win32 only ;) You will have to come up with some other mechanism for NGC/PS2, although I suppose you could extract the parameter info from your Win32 exe and use it to generate some sort of tables that you can link into the NGC/PS2 version. But then, you might as well just use SWIG, or even Doxygen to scan your code to generate the export tables. That's what I do :) Oh, and for the record we use LUA. I looked at Python but it seems too heavy and sluggish for scripting our games. But then, I didn't really try using it in anger so it may work better than LUA in practice. LUA seems ok so far and "if it ain't broke..." so I guess I may never find out ;) Cheers, Stef! :) -- Stefan Boberg, R&D Manager - Team17 Software Ltd. bo...@te... ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=556 |
|
From: Jacob T. (C. D. Ltd) <Ja...@Co...> - 2002-07-12 13:29:03
Attachments:
InterScan_Disclaimer.txt
|
> All you really need is a way to get the code segment position of the functions This is the easy bit using the map file or the gcc tools that can be used to decode an elf file > to and to work out the name mangling/variable passing stuff. Hmmm, that is the more fun bit. There doesn't seem to be exact documentation on how GCC passes stuff around on the PS2. The MIPS argument passing standard is well known. Using a dissassembler on existing code and functions is the way to discover how everything gets passed -----Original Message----- From: Gareth Lewin [mailto:GL...@cl...] Sent: 12 July 2002 14:21 To: gam...@li... Subject: RE: [GD-Design] Scripting Engine and C++ Games I talked to our NGC/PS2 people about this kind of stuff, apparently the NGC has some kind of dynamic linking, but not the ps2. Both were just idle discussions, neither were really tested. Note that Fubi works wonders on the xbox, even though it doesn't support dynamic linking, so perhaps you could export stuff on the NGC/PS2 just because gcc happens to support that for other targets. All you really need is a way to get the code segment position of the functions and to work out the name mangling/variable passing stuff. -----Original Message----- From: Stefan Boberg [mailto:sbo...@te...] Sent: 12 July 2002 14:15 To: gam...@li... Subject: RE: [GD-Design] Scripting Engine and C++ Games > Take a look at http://www.drizzle.com/~scottb/gdc/fubi-paper.htm > > We are using it and are extremly happy with it, thanks Scott ;) > > Ofcourse you can still write whatever syntax for the laungage you want, or > use Lua/Python/Tcl ( Those seem to be the most commonly used ), but Fubi > is definitly the way to connect the scripting language up with the game. ... iff you are targeting Win32 only ;) You will have to come up with some other mechanism for NGC/PS2, although I suppose you could extract the parameter info from your Win32 exe and use it to generate some sort of tables that you can link into the NGC/PS2 version. But then, you might as well just use SWIG, or even Doxygen to scan your code to generate the export tables. That's what I do :) Oh, and for the record we use LUA. I looked at Python but it seems too heavy and sluggish for scripting our games. But then, I didn't really try using it in anger so it may work better than LUA in practice. LUA seems ok so far and "if it ain't broke..." so I guess I may never find out ;) Cheers, Stef! :) -- Stefan Boberg, R&D Manager - Team17 Software Ltd. bo...@te... ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=556 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=556 |
|
From: Stewart L. <St...@cl...> - 2002-07-12 15:46:57
|
Hello,
I've implemented FUBI and so far I really like it, although it has yet to be
really stretched by the designers. I am interested in your approach, but I'm
not sure I follow exactly. Are you saying that you generated ICE interface
classes from the C++ code and then the system shadowed the system objects in
the scripting engine? or have I got the wrong end of the stick.
Our script compiler doesn't know anything about the game api, it uses a
.fubi file for the compilation of the scripts. The script engine also has no
knowledge of the game api, it just reads in the fubi file and that allows
any of the exported C++ functions to be called from script. What I liked
about FUBI was the way that it integrates the scripting language with the
C++ game code without the script compiler or engine having to be coupled to
the game at all, but I'm always open to new ideas.
We did look at a lot of the scripting languages out there, but still decided
to write our own because none of them met our specific needs, and as someone
else pointed out it is really important to take the end user of the language
into consideration. If the scripting language is for programmers lua or
python might be fine, but if it is for non-programmers/designers something
even more simple that's suited to the game might be needed. I don't see much
point in having a scripting language that is as complex as C++, the power of
a scripting language is that it should be a much higher level language that
simplifies tasks for creating the game. I think there's a real danger of
scripting languages getting too complex and loosing their initial aim. It'll
be interesting to see how much of our game actually gets written in script.
thanks for sharing your method, I find it a really interesting topic.
Stew.
-----Original Message-----
From: Kent Quirk [mailto:ken...@co...]
Sent: 12 July 2002 15:37
To: LordEidi
Cc: gam...@li...
Subject: Re: [GD-Design] Scripting Engine and C++ Games
Given that everyone's talking about FUBI, I wanted to talk for a
minute about what we did with MindRover, because I think it's a really
good solution and quite a bit different in philosophy.
We built our own scripting language, ICE, which is semantically nearly
identical to Java (though the syntax looks more like BASIC).
By the way, I wouldn't recommend doing your own scripting language --
when we did it, 4 years ago, there wasn't much around that was robust
enough for game use. But now there are a lot of freely available
solutions for a language.
Anyway, the part I wanted to talk about was the interface to our core
code.
What we did was build a scripting language compiler that had NO
KNOWLEDGE of the API presented by the game. None at all.
The game's C++ engine could export functions to the API. The API was
chopped up into a set of classes we called SystemObjects. There was a
VehicleSystemObject, for example. You could (with a command line
switch) as the C++ engine to write the interface base classes in ICE
for all system objects, so we'd get a hunk of code that looked like:
'-------VehicleSystemObject------------
class VehicleSystemObject extends SystemObject
function setEngine(speed as integer, vehID as integer) as boolean
' This is an interface with no functionality
end function
...
end class
'-------VehicleSystemObject------------
When you compiled code for the game, you could use a
VehicleSystemObject. But the compiler only saw the interface class
shown above -- there was no functionality visible to the compiler.
The key was in the call to create a VehicleSystemObject. You didn't
just do:
VehicleSystemObject vso = new VehicleSystemObject()
Instead, you'd have to ask the game system for one:
VehicleSystemObject vso = system.loadVehicle("myvehicle")
What happened internally was that the system would manufacture a
ShadowVehicleSystemObject, which is a subclass of VehicleSystemObject
that actually had functionality, and return it.
The "system" object was passed in on the constructor of the class,
which is how the whole thing was bootstrapped.
What this all boiled down to was that we have a completely generic
external compiler that knows NOTHING about any game API. The game, in
turn, loads external code completely generically. There's one piece of
code that knows how to construct a class that the language system can
understand, and it simply operates on a table of functions set up in
the C++ code.
Changes to the API simply mean regenerating the base classes and
possibly recompiling external scripts that use them if the interfaces
have changed (we made the system robust across different versions of
class interfaces so we could release updates in the field without
forcing everyone to recompile everything).
One nice thing about this system is that it let us easily build a
standalone execution system for the language. We built a trivial API
that only provides the ability to log a few things to a file, but that
was enough to let us construct a rather significant (150 source files)
language compatibility test suite that's completely automated.
Whenever we make a change to the language we can run the suite and
make sure we haven't broken anything.
Anyway, it's a quite different philosophy than the FUBI stuff. I like
it because it keeps the game engine, the scripting language, and the
scripting API at arm's length, whereas FUBI tends to bind them all
rather closely, which can lead to maintenance issues down the road.
Kent
Friday, July 12, 2002, 7:04:11 AM, you wrote:
> We from SwordLord.com are currently coding for a new game. This game
> should contain a scripting engine with the idea to help us to script many
> of the games features instead of hardcode them in c++. Also level
> designers could add to the games behaviour like that. (As more script in
> the game as happier I am ;))
> We are currently in the design and architecture phase of that scripting
> engine and would like to hear comments, suggestions, tips and read some
> good texts on that topic. Especially on the topic of how to knit the
> scripting and the c++ part together. How they both interact.
> Has any of you some experience on that topic and could help us with some
> tips or could supply us with a link to a good website or book?
--
Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=556
|
|
From: Kent Q. <ken...@co...> - 2002-07-12 17:44:21
|
> I've implemented FUBI and so far I really like it, although it has yet to be > really stretched by the designers. I am interested in your approach, but I'm > not sure I follow exactly. Are you saying that you generated ICE interface > classes from the C++ code and then the system shadowed the system objects in > the scripting engine? or have I got the wrong end of the stick. The C++ code had a table of functions internally with additional metadata. The C++ code could generate interface classes in ICE, that were used by the ICE compiler. At runtime, the C++ code manufactures functional ICE object code (which calls the C++ functions) as a subclass (the ShadowSystemObject) of the interface class. Another benefit of this, by the way, is security. Our ICE compiler will NEVER generate object code to escape into the C++ code. In fact, it doesn't even know there's an instruction to do so. The only place that instruction is ever inserted is in the ShadowSystemObject. The result is that it's literally impossible to write code in our scripting language that can do anything the game API doesn't explicitly permit, which was important given that we intended to permit end users to exchange running ICE code. > Our script compiler doesn't know anything about the game api, it uses a > .fubi file for the compilation of the scripts. The script engine also has no > knowledge of the game api, it just reads in the fubi file and that allows > any of the exported C++ functions to be called from script. What I liked > about FUBI was the way that it integrates the scripting language with the > C++ game code without the script compiler or engine having to be coupled to > the game at all, but I'm always open to new ideas. I guess my problem with FUBI is that it's very platform-specific and even compiler-specific. Our approach with ICE has so far been ported to Linux, Mac, and PC -- and code compiled on any one of them runs without change on all of the others. The other thing I dislike about it is that because of its functional nature, it's my belief that it would tend to promote poorly designed engine APIs. But I recognize that's more of a religious argument than a technical one. > We did look at a lot of the scripting languages out there, but still decided > to write our own because none of them met our specific needs, and as someone > else pointed out it is really important to take the end user of the language > into consideration. If the scripting language is for programmers lua or > python might be fine, but if it is for non-programmers/designers something > even more simple that's suited to the game might be needed. I don't see much > point in having a scripting language that is as complex as C++, the power of > a scripting language is that it should be a much higher level language that > simplifies tasks for creating the game. I think there's a real danger of > scripting languages getting too complex and loosing their initial aim. It'll > be interesting to see how much of our game actually gets written in script. Yes, you've hit on a big part of the reason for ICE. We wanted a language that end users could use. But we also wanted a language that could support a robust, object-oriented coding style, because we expected to write huge portions of our game in it. We shipped 40K lines of ICE code as part of the game. I do think you should think seriously about your programming language design. You can design for simplicity, but just make sure it's the right kind of simplicity. All too often, simplicity of implementation is confused with simplicity of language design. There are a lot of bad scripting languages around that were easy to write but are not so easy to use. -- Kent Quirk, CTO, CogniToy ken...@co... http://www.cognitoy.com |
|
From: Mickael P. <mpo...@ed...> - 2002-07-19 09:36:52
|
> Yes, you've hit on a big part of the reason for ICE. We wanted a
> language that end users could use. But we also wanted a language that
> could support a robust, object-oriented coding style, because we
> expected to write huge portions of our game in it. We shipped 40K
> lines of ICE code as part of the game.
>
> I do think you should think seriously about your programming language
> design. You can design for simplicity, but just make sure it's the
> right kind of simplicity. All too often, simplicity of implementation
> is confused with simplicity of language design. There are a lot of bad
> scripting languages around that were easy to write but are not so easy
> to use.
As usual it's a matter of requirements. Before deciding for any kind of
script language you have to know who will be using that language. So far
I've worked on two projects where 100% of the game logic was made using
a scripting language: "Little Big Adventure" (LBA) and "Time Commando".
We know from the start for both those projects that a part of game coding
will be done by people with almost no experience in programming, so we
decided to make something very simple (and well, it was in 1995...) that
even a non programmer would be able to understand. And I have to say that
the result was ok. The game itself is perhaps not that good, but almost
everybody was capable of pointing out bugs in behaviors by looking into
the source code.
For those interested, here is the complete source code (I just translated
the french names in english for understandability) of the behavior of the
"Sabertooth tiger" encountered in the level 1 of Time Commando:
=====================================
StartProgram Tiger // Last update Mike: Sun 02/06/96
//
// While the hero is not around here, do nothing
// if the hero arrived at less than 2 meters of
// distance, start roaring.
//
DoAnimRepeat Nothing
If GetDistance(Hero)>3000 AND !TestTouched
SetBeta 460
WaitDistance 6000
DoAnimRepeat Walk
Wait GetDistance(Hero) < 2000 OR TestTouched
If GetDistance(Hero) > 2000 AND !TestTouched
DoAnimRepeat Guard
FollowHero
DoAnimOnce Roar
WaitAnim
EndIf
EndIf
//
// The hero is now in the fight area.
//
Loop
FollowHero
DoAnimRepeat Guard
While TestAlive(Hero)
distance_hero=GetDistance(Hero)
If GetSameHit > 2 AND GetDifficulty <> 0
Fury Furie
WaitAnim
ResetSameHit
ElseIf distance_hero > 3200
//
// At more than 3.2 meter, approach slowly
//
DoAnimRepeat Walk
ElseIf distance_hero >= 3000
//
// Between 3m et 3.2m, use the long jump
//
DoAnimOnce GetValueList(-1, LongJumpAttack, Roar)
WaitAnim
ElseIf TestBetween(distance_hero,700,900)
//
// Closer, try to bite
//
DoAnimOnce GetValueList(-1, BiteAttack, Guard)
WaitAnim
ElseIf distance_hero < 700
//
// If too close for efficient hitting, get back or bite
//
If GetRandom(1)
DoAnimOnce Recule
Else
DoAnimOnce GetValueList(-1, BiteAttack, Guard)
EndIf
WaitAnim
ElseIf distance_hero > 1900
//
// At more than 1,90m, stay on guard
// and from time to time launch a roar.
//
DoAnimRepeat Guard
If !GetRandom(10)
DoAnimOnce GetValueList(-1, Roar, LongJumpAttack, Guard)
WaitAnim
Endif
Else
//
// Hand to hand distance
//
If TestHeroAttacking & GetRandom(1)
DoAnimOnce Recule
Else
DoAnimOnce GetValueList(-1, ClawAttack, Guard)
Endif
WaitAnim
Endif
ExitProgram
EndWhile
UnFollow
DoAnimRepeat Nothing
DoAnimOnce Roar
Wait TestAlive(Hero)
ExitProgram
EndLoop
EndProgram
=====================================
It will certainly not win any award for engeeniering quality, but
it was easy to code, easy to maintain, easy to extend.
Please note that the language as a very special notion of case
sensitiveness, that helps us a lot during production: It's case
sensitive in the meaning that when you write something in a certain
form, you have to use this form later. So it avoids people writing
"Hero", "hero", "HERO" to indicate the same thing... but there is
also a case insensitive check on each new encountered symbol, so
you cannot have to variable/keywords/functions/objects that have
the same name differently only by the case.
Mickael Pointier
|
|
From: <phi...@pl...> - 2002-07-12 17:40:07
|
SN systems supply DLL support in their current PS2 toolchain. AFAIK it's
not part of the Sony tool chain, and I have no idea if codewarrior supports
it, although I'd expect them to.
It's very clean, you handle all the loading, and just pass a pointer to the
buffer in memory to an init function.
Cheers,
Phil
(Not affiliated with SN, just a very satisfied customer)
Gareth Lewin <GL...@cl...>
Sent by: To: gam...@li...
gam...@li...urc cc:
eforge.net Subject: RE: [GD-Design] Scripting Engine and C++ Games
07/12/2002 06:21 AM
I talked to our NGC/PS2 people about this kind of stuff, apparently the NGC
has some kind of dynamic linking, but not the ps2. Both were just idle
discussions, neither were really tested.
Note that Fubi works wonders on the xbox, even though it doesn't support
dynamic linking, so perhaps you could export stuff on the NGC/PS2 just
because gcc happens to support that for other targets.
All you really need is a way to get the code segment position of the
functions and to work out the name mangling/variable passing stuff.
-----Original Message-----
From: Stefan Boberg [mailto:sbo...@te...]
Sent: 12 July 2002 14:15
To: gam...@li...
Subject: RE: [GD-Design] Scripting Engine and C++ Games
> Take a look at http://www.drizzle.com/~scottb/gdc/fubi-paper.htm
>
> We are using it and are extremly happy with it, thanks Scott ;)
>
> Ofcourse you can still write whatever syntax for the laungage you
want, or
> use Lua/Python/Tcl ( Those seem to be the most commonly used ), but
Fubi
> is definitly the way to connect the scripting language up with the
game.
... iff you are targeting Win32 only ;) You will have to come up with
some other mechanism for NGC/PS2, although I suppose you could extract
the parameter info from your Win32 exe and use it to generate some sort
of tables that you can link into the NGC/PS2 version. But then, you
might as well just use SWIG, or even Doxygen to scan your code to
generate the export tables. That's what I do :)
Oh, and for the record we use LUA. I looked at Python but it seems
too heavy and sluggish for scripting our games. But then, I didn't
really try using it in anger so it may work better than LUA in practice.
LUA seems ok so far and "if it ain't broke..." so I guess I may never
find out ;)
Cheers,
Stef! :)
--
Stefan Boberg, R&D Manager - Team17 Software Ltd.
bo...@te...
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=556
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=556
|
|
From: Ken P. <ke...@dr...> - 2002-07-14 07:46:38
|
G'day! I'm taking a shot at embedding perl and so far it seems fairly easy. The problem I'm running into is that all the tools are command line only (auto-processing of glue code and such). Don't get me wrong, it's not that I have issues with using command-line tools, I have issues using them under Windows. The command prompt in Win2K is a big improvement over what existed in Win98, but it's still not even close to a nice XTerm-style shell. Part of that is lack of a decent shell (tcsh/bash/whatever) and part is the poor handling of the window. At this point I'm considering trying to set up a telnet daemon on my Win2k machine and telnetting to localhost because CRT (a very nice telnet client BTW) gives me a nicer interface to command-line stuff than Window's command prompt. Does anyone know of any decent (free or cheap) XTerm & unix-like shell products? KDE For Windows would be nice. :) Stay Casual, Ken |
|
From: Parveen K. <pk...@sf...> - 2002-07-14 09:01:37
|
Ken Paulson wrote: [...] > Does anyone know of any decent (free or cheap) XTerm & unix-like shell > products? Try cygwin. It's hard to beat the flexibility of *nix command shells. It's burdensome to use CVS on windows without it (unless your using wincvs). > KDE For Windows would be nice. :) Yeah, a KDE customized is much nicer than the vanilla windows desktop. I have friends that have been succesfully running KDE on W2K using cygwin. I haven't done it personally though. http://kde-cygwin.sourceforge.net/ Although, it ran pretty slow on a P2-350, 128MB, W2K. Now all we need is a hardware accelerated, double buffered desktop. |
|
From: J C L. <cl...@ka...> - 2002-07-14 15:51:11
|
On Sun, 14 Jul 2002 02:39:49 -0500 Ken Paulson <ke...@dr...> wrote: > Does anyone know of any decent (free or cheap) XTerm & unix-like shell > products? KDE For Windows would be nice. :) Cygwin ships with rxvt. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: Gareth L. <GL...@cl...> - 2002-07-15 09:00:32
|
I have been using 4dos ( and now 4nt ) for years now, and I personally prefer it over unix shells, except for maybe bash. -----Original Message----- From: Ken Paulson [mailto:ke...@dr...] Sent: 14 July 2002 08:40 To: gam...@li... Subject: RE: [GD-Design] Scripting Engine and C++ Games G'day! I'm taking a shot at embedding perl and so far it seems fairly easy. The problem I'm running into is that all the tools are command line only (auto-processing of glue code and such). Don't get me wrong, it's not that I have issues with using command-line tools, I have issues using them under Windows. The command prompt in Win2K is a big improvement over what existed in Win98, but it's still not even close to a nice XTerm-style shell. Part of that is lack of a decent shell (tcsh/bash/whatever) and part is the poor handling of the window. At this point I'm considering trying to set up a telnet daemon on my Win2k machine and telnetting to localhost because CRT (a very nice telnet client BTW) gives me a nicer interface to command-line stuff than Window's command prompt. Does anyone know of any decent (free or cheap) XTerm & unix-like shell products? KDE For Windows would be nice. :) Stay Casual, Ken ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=556 |
|
From: Stewart L. <St...@cl...> - 2002-07-15 09:39:54
|
I agree that FUBI is very platform specific, although I think it could be implemented on any platform without too much trouble. In our case this doesn't matter, but I can se how this would be a drawback for some games. I also accept your argument that the api could become very messy and poorly designed, it's almost too easy to export functions. We are taking measures to avoid this such as extensive help documentation, but it's definitely something I'll watch out for. From a development point of view it is very useful having such a flexible api, it's very easy to export a function and write a quick script to test something, it has dramatically reduced C++ code pollution. So far it's been only the programmers using the language and so the flexibility is really useful. I'm interested to see what starts to happen when the designers start pushing it. Yes, by simplicity I did mean simplicity from the designers point of view, the compiler and engine are definitely not simple. ;) The big difference is that my scripting language was designed to make simple tasks simple to implement. Our end user will never see the scripting language, and us programmers will probably still mostly be using C++. There's always a trade off between flexibility and rigid structure, so far in our game flexibility has won outright, but we may have to nail things down as the project starts to grow. If I ever have to implement a more extensive scripting language I will definitely consider your approach, thanks. Stew. -----Original Message----- From: Kent Quirk [mailto:ken...@co...] Sent: 12 July 2002 18:44 To: Stewart Lynch Cc: gam...@li... Subject: Re: [GD-Design] Scripting Engine and C++ Games > I've implemented FUBI and so far I really like it, although it has yet to be > really stretched by the designers. I am interested in your approach, but I'm > not sure I follow exactly. Are you saying that you generated ICE interface > classes from the C++ code and then the system shadowed the system objects in > the scripting engine? or have I got the wrong end of the stick. The C++ code had a table of functions internally with additional metadata. The C++ code could generate interface classes in ICE, that were used by the ICE compiler. At runtime, the C++ code manufactures functional ICE object code (which calls the C++ functions) as a subclass (the ShadowSystemObject) of the interface class. Another benefit of this, by the way, is security. Our ICE compiler will NEVER generate object code to escape into the C++ code. In fact, it doesn't even know there's an instruction to do so. The only place that instruction is ever inserted is in the ShadowSystemObject. The result is that it's literally impossible to write code in our scripting language that can do anything the game API doesn't explicitly permit, which was important given that we intended to permit end users to exchange running ICE code. > Our script compiler doesn't know anything about the game api, it uses a > .fubi file for the compilation of the scripts. The script engine also has no > knowledge of the game api, it just reads in the fubi file and that allows > any of the exported C++ functions to be called from script. What I liked > about FUBI was the way that it integrates the scripting language with the > C++ game code without the script compiler or engine having to be coupled to > the game at all, but I'm always open to new ideas. I guess my problem with FUBI is that it's very platform-specific and even compiler-specific. Our approach with ICE has so far been ported to Linux, Mac, and PC -- and code compiled on any one of them runs without change on all of the others. The other thing I dislike about it is that because of its functional nature, it's my belief that it would tend to promote poorly designed engine APIs. But I recognize that's more of a religious argument than a technical one. > We did look at a lot of the scripting languages out there, but still decided > to write our own because none of them met our specific needs, and as someone > else pointed out it is really important to take the end user of the language > into consideration. If the scripting language is for programmers lua or > python might be fine, but if it is for non-programmers/designers something > even more simple that's suited to the game might be needed. I don't see much > point in having a scripting language that is as complex as C++, the power of > a scripting language is that it should be a much higher level language that > simplifies tasks for creating the game. I think there's a real danger of > scripting languages getting too complex and loosing their initial aim. It'll > be interesting to see how much of our game actually gets written in script. Yes, you've hit on a big part of the reason for ICE. We wanted a language that end users could use. But we also wanted a language that could support a robust, object-oriented coding style, because we expected to write huge portions of our game in it. We shipped 40K lines of ICE code as part of the game. I do think you should think seriously about your programming language design. You can design for simplicity, but just make sure it's the right kind of simplicity. All too often, simplicity of implementation is confused with simplicity of language design. There are a lot of bad scripting languages around that were easy to write but are not so easy to use. -- Kent Quirk, CTO, CogniToy ken...@co... http://www.cognitoy.com |
×
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