gamedevlists-design Mailing List for gamedev (Page 10)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-design — List for discussing game development design
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(1) |
Nov
(37) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(15) |
Jul
(38) |
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
| 2003 |
Jan
(6) |
Feb
(60) |
Mar
|
Apr
(41) |
May
|
Jun
(3) |
Jul
(19) |
Aug
(15) |
Sep
|
Oct
(11) |
Nov
|
Dec
(12) |
| 2004 |
Jan
(15) |
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
(9) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
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 |
|
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: 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: 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: 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: 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: <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: 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 14:37:21
|
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
|
|
From: Jacob T. (C. D. Ltd) <Ja...@Co...> - 2002-07-12 13:29:03
|
> 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: 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: 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 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: 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: Jamie F. <ja...@qu...> - 2002-07-12 11:11:57
|
to my mind the most underrated piece of advice is: know your scriptwriters. some are happy writing C code (even if they don't know it :), some want something very simple to write, and some want something in between. oh, and look at the existing solutions out there before writing your own :) i'm sure a google / archive search on this will throw up loads of stuff. jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of LordEidi 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: LordEidi <lor...@sw...> - 2002-07-12 11:04:19
|
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 |
|
From: Ivan-Assen I. <as...@ha...> - 2002-07-11 18:06:45
|
> I *really* like this idea. Could you tell the the name of this book, so > I can drop the name as "required reading" to our design department :-) http://www.amazon.com/exec/obidos/ASIN/1576104257/103-3231798-0138217 Game Architecture and Design. Trivia: author is designer of Warrior Kings, among other things. However, that game definitely looked better in the book than IRL :-( regards, Assen |
|
From: Ivan-Assen I. <as...@ha...> - 2002-07-11 16:26:00
|
guess what? reply-to-sender... ----- Original Message ----- From: "Ivan-Assen Ivanov" <as...@ha...> To: "Javier Arevalo" <ja...@py...> Sent: Thursday, July 11, 2002 12:52 PM Subject: Re: [GD-Design] GTA II Review > > Have to admit, I was rather relieved that the piece turned out to be > > very positive, given the games subject matter. Although I don't know > > if I'd call GTA3 'hardcore'. I tend to use that label for games with > > vertical learning curves, or excessive difficulty levels, i.e. only > > the hardcore will actually play them. E.g. Gunvalkyrie is hardcore, > > because only a compete nutter would persist past it's willfully > > difficult control system. Most scrolly shooters are hardcore, because > > if you're not 'in the zone' you get completely obliterated in seconds. > > A nice book I read recently gave a surprising but very appropriate IMO > definition of hardcore gamers: hardcore gamers are those who judge a game > by its own merits - gameplay, graphics, etc - rather than buying into > licenses and sequels. > > Concepts like "balance" and "challenge" are very hardcore. The general public > doesn't want to have Spiderman balanced out against the Green Goblin; > the general public wants to push the "X" button 3000 times, and in > response to that Spiderman to do 30 hours worth of interesting things > and be victorious at the end. > > GTA3 contains some pretty hardcore violence, but violence is a > general, non-gaming-specific concept, and very popular at that, so > I think GTA3 is NOT a hardcore game. Its appeal lies in simple things, > instantly familiar to the huge majority of people: leisurely cruising around > on a car of your choice, and beating the sh*t out of anybody. > > regards, > Assen > |
|
From: Javier A. <ja...@py...> - 2002-07-11 09:36:44
|
phi...@pl... wrote: > Have to admit, I was rather relieved that the piece turned out to be > very positive, given the games subject matter. Although I don't know > if I'd call GTA3 'hardcore'. I tend to use that label for games with > vertical learning curves, or excessive difficulty levels, i.e. only > the hardcore will actually play them. E.g. Gunvalkyrie is hardcore, > because only a compete nutter would persist past it's willfully > difficult control system. Most scrolly shooters are hardcore, because > if you're not 'in the zone' you get completely obliterated in seconds. My personal definition of "hardcore" includes "counterintuitive gaming principles that only a dedicated gamer with years on his back is aware of (or interested in)". Stuff like: - shooting at the powerup pills to change the powerup they provide (shooters) - AD&D rules in order to make sense out of skills & stats (many RPGs) - excruciatingly complex subgoals in order to reveal easter eggs / extra stuff (Final Fantasies) - based on a hardcore gaming license (Maximo?) - using many iconic or "plain weird" elements in its gaming universe (I guess Mario or Sacrifice)... Anti-hardcore would be stuff like: - use well-known characters, licenses and game universes (GTA3, Commandos) - use established game interfaces without assuming the player knows them (the boring 1st tutorial we all skip) - contain game interface helper elements (even Windows elements like tooltips) - avoid killing the player (Was Larry the first one to do this?) - player always knows what to do, doesn't have to search for it himself. A game would be hardcore if it contains too many hardcore elements for the average joe. |
|
From: <phi...@pl...> - 2002-07-11 01:25:10
|
Have to admit, I was rather relieved that the piece turned out to be very
positive, given the games subject matter. Although I don't know if I'd call
GTA3 'hardcore'. I tend to use that label for games with vertical learning
curves, or excessive difficulty levels, i.e. only the hardcore will
actually play them. E.g. Gunvalkyrie is hardcore, because only a compete
nutter would persist past it's willfully difficult control system. Most
scrolly shooters are hardcore, because if you're not 'in the zone' you get
completely obliterated in seconds.
Cheers,
Phil
"Albert Reed"
<al...@de...> To: <gam...@li...>
Sent by: cc:
gam...@li...urc Subject: [GD-Design] GTA II Review
eforge.net
07/10/2002 10:07 AM
It's not everyday that mainstream news media actually reviews a game,
rather than reporting on it. NPR's All Things Considered presented a
rather interesting review of Grand Theft Auto III yesterday, well-worth
the listen.
http://www.npr.org/ramfiles/atc/20020709.atc.10.ram
I love hearing non-gamer viewpoints on games which are more-or-less
pegged as "hardcore" games. Perhaps this label we put on so many games
is becoming less relevant today.
Al
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
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: Albert R. <al...@de...> - 2002-07-10 17:06:49
|
It's not everyday that mainstream news media actually reviews a game, rather than reporting on it. NPR's All Things Considered presented a rather interesting review of Grand Theft Auto III yesterday, well-worth the listen. http://www.npr.org/ramfiles/atc/20020709.atc.10.ram I love hearing non-gamer viewpoints on games which are more-or-less pegged as "hardcore" games. Perhaps this label we put on so many games is becoming less relevant today. Al |
|
From: brian h. <bri...@py...> - 2002-06-26 15:07:08
|
> We use floating small panels in our game, and it seems to work fairly > well. All panels can be dragged around just by gripping the border and > dragging. All panels can also be hidden. > http://civil.sourceforge.net/screenshots/snapshot56.jpg (BTW, looks neat!) > This is a slow paced strategy game, where the player has time to arrange > the "environment" to suit his/her taste. Ah, that's the rub. For a faster paced game, like an RTS or a real- time RPG, I would imagine that the windows would get in the way. Nothing more frustrating that trying to target an enemy unit that crawled under one of your windows. =| -Hook |
|
From: Tom F. <to...@mu...> - 2002-06-26 13:59:37
|
> -----Original Message----- > From: Tom Hubina [mailto:to...@3d...] [snip] > Actually .. this isn't accurate any more (and hasn't been for > quite some > time). Right now my buddy runs a GeForce2 as primary AGP, and > PCI TNT card > as secondary. Both are hardware accelerated with OpenGL. The > place where > things get ugly is when a window straddles two monitors ... > only the part > of the window on the display where the window was created still works > properly by default ;) If a window moves from one monitor to > another, you > can destroy the old RC and get a new one within that monitor and get > acceleration again. You _might_ even be able to use the > shared texture and > display list stuff and only use one copy of textures and > display lists for > dual-head cards ... but that's probably a stretch ;) > > I don't know how things work with mutli-mon and going full screen .. > specifically switching resolutions and generally dealing with > devices, but > I suspect there's some form of solution. Sorry, my bad. I haven't kept up with multimon OGL for a while. So now it's just as klunky as DirectX 8 is, i.e. two devices, two contexts, two copies of everything and all that. Gagh. That's far too much work for most apps to cover such a tiny portion of the market. [snip] > >So I'm going to express cautious support for multimonitor, > especially if > >using DX9 and shipping in a year or so. But it is cautious. > > I wouldn't make multi-mon a required feature ... nor would I > put a lot of > effort into it. Maybe a couple of days or a week ... tops. There just > aren't enough people that use it yet. Agreed. The problem is that "a couple of days" doesn't sound like long enough to port any engine to knowing about multiple contexts, which seems to be what is required under both OGL and DX8. Things should be better in DX9. Obviously it's still in beta right now, but it looks like you can simply create a second display chain of surfaces, SetRenderTarget to them, render your scene, and it all Just Works. Now _that_ is something that would only take a few days, assuming you already had the concept of multiple viewports in your rendering engine (which most do). > Tom 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. |
|
From: Tom H. <to...@3d...> - 2002-06-26 12:52:24
|
At 03:25 AM 6/26/2002, Tom Forsyth wrote: >If using OpenGL, the moment you enable the second monitor, all hardware >rendering support vanishes. Various IHVs have fudged it so it doesn't (by >tricking Windows into thinking it's running on a single large monitor) but >that causes all sorts of problems of its own, especially the different-sized >monitor case. Actually .. this isn't accurate any more (and hasn't been for quite some time). Right now my buddy runs a GeForce2 as primary AGP, and PCI TNT card as secondary. Both are hardware accelerated with OpenGL. The place where things get ugly is when a window straddles two monitors ... only the part of the window on the display where the window was created still works properly by default ;) If a window moves from one monitor to another, you can destroy the old RC and get a new one within that monitor and get acceleration again. You _might_ even be able to use the shared texture and display list stuff and only use one copy of textures and display lists for dual-head cards ... but that's probably a stretch ;) I don't know how things work with mutli-mon and going full screen .. specifically switching resolutions and generally dealing with devices, but I suspect there's some form of solution. >Under DirectX, you can use multimonitor, and have been able to do for some >time, but itmeans keeping track of multiple devices, each with its own set >of texture, VBs, etc, even though they actually all live on the same card. >This is changing for the better in DX9 I believe, so that a single device >can have multiple RAMDAC surfaces (which is the way to go), but it does >require new driver support, etc - so you need to decide when you're shipping >and what the market support will be. I'm not personally familiar with things under DX at the moment, but that sounds accurate. >So I'm going to express cautious support for multimonitor, especially if >using DX9 and shipping in a year or so. But it is cautious. I wouldn't make multi-mon a required feature ... nor would I put a lot of effort into it. Maybe a couple of days or a week ... tops. There just aren't enough people that use it yet. Tom |
|
From: Tom F. <to...@mu...> - 2002-06-26 10:33:21
|
> -----Original Message----- > From: ham...@tm... [mailto:ham...@tm...] > Please note that 3 can have an extra advantage, depending on > precisely how much the implementation fits within the mores > of whichever OS(es) it runs on: thanks especially to nVidia, Ouch - careful with that hype - you'll have someone's eye out. IIRC, nVidia were almost the last major IHV to introduce multi-monitor cards. > an awful lot of "normal" games-playing people now have two or > more monitors on their PC - it's no longer the preserve of > professional graphic artists etc - and number 3 allows them > to actually take advantage of that extra monitor, without the > GUI designer having the headache of designing specifically > for multi-monitor. [snip] > [confession: I tend to get really pi**ed off when a game with > loads of dialogues refuses to play nice with multi monitor - > I've got the hardware, I got it working under > windows/X11/whatever, and its extremely frustrating not to be > bale to use it]. The problem with multimonitor is that it's a huge pain at the moment. If using OpenGL, the moment you enable the second monitor, all hardware rendering support vanishes. Various IHVs have fudged it so it doesn't (by tricking Windows into thinking it's running on a single large monitor) but that causes all sorts of problems of its own, especially the different-sized monitor case. Under DirectX, you can use multimonitor, and have been able to do for some time, but itmeans keeping track of multiple devices, each with its own set of texture, VBs, etc, even though they actually all live on the same card. This is changing for the better in DX9 I believe, so that a single device can have multiple RAMDAC surfaces (which is the way to go), but it does require new driver support, etc - so you need to decide when you're shipping and what the market support will be. So I'm going to express cautious support for multimonitor, especially if using DX9 and shipping in a year or so. But it is cautious. > Adam M 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. |
8 messages has been excluded from this view by a project administrator.
