Scripting is very important, whether you're allowing external editing of your game or not. More important than scripting is the ability to create an interface to your game 'core' engine so that you can exend it (either with scripts or with the DLL concept talked about earlier). The majority of game logic actions could be done with a function-call. If you create an interface layer so that the engine calls this layer rather than the script/DLL you can develop interchangable systems. Black-boxing is important for reuse.

The main thing this means to you, the programmer is that you have the ability to reuse your game engine components, throwing bits that change (the logic) into scripts / DLL-based systems.

The important thing is, you have you plan in advance about how and why you're using scripts because a half-assed implementation of a scripting engine is next to useless.

Don't forget that scripting doesn't have to be a C++ like language, some projects get by with a simple parameterised command language with a few basic conditional statements.

Quote: Original post by Nemesis2k2
Look at it this way, how much of that "lingua franca" is handled by functions? How many of those game specific operations are going to be achieved by calling a function which does most of the work for you?

Admittedly, some. But by no means all. My scripting language (an extension of Lua) has extensive support for coordinating multiple simultaneous actions, because that's what I need it for. I can't do that in C++; the lack of things like anonymous function closures and automatic thread safety makes it far too onerous.

Quote: I don't want my function definitions in these DLL's to be massively long for example, and include stuff like "extern". The person writing the script shouldn't have to worry about that stuff. That's where you use macros.

Ahh, macros are where it starts. Then come the other macros, and the weird templated functions, and the operator overloading abuse, and the debugging facilities to keep it all working-ish. See boost::spirit and boost::lambda for what I'm talking about. At a certain point, and for many projects I think that point is not far off, you have to reconsider how much extra work _not_ adding another language is. The emergence of language constructs specific to a particular application is inevitable, and a scripting language lets you deal with them more naturally.

I disagree about the same issues being involved in C as with another programming language. Examples include garbage collection, function prototyping, header files, C strings, structures, memory allocation, etc. Scripting is there to decrease the development time of the game, whether it be for the lone developer or for a full-fledged modding community. How often do you fire up a compiler for something a simple sh script could do? Scripting languages allow you to target in on what you are doing, as opposed to worrying about messy syntax or something or other. Scripts are meant to be straightforward and simple, as opposed to writing a quicksort function or a GUI system. With scripting, it's things like move character left 2 tiles; have them say this and that; if they have this item then do this. Scripting is perfect for this.

If you think that coding in C is the same as coding in Python, you've obviously never coded in Python. I've written things so fast in Python it makes my head spin. And it's easy to say right now "Oh, a recompile will take a little time but it's not bad" you'll be reconsidering that when you're trying to figure out the perfect animation delay for a sprite. Or getting a character to walk over 3 more pixels than before. Filling a game with content is a long and tedious task; it's best to make it as easy as possible.

All of this doesn't matter if you are writing a PacMan clone or an RPG with a town and a cave. But any semi-large-scale project will be well worth the time looking into a scripting language. I guess the best way to find out is experience though.

Quote: Original post by Anonymous Poster
And it's easy to say right now "Oh, a recompile will take a little time but it's not bad" you'll be reconsidering that when you're trying to figure out the perfect animation delay for a sprite. Or getting a character to walk over 3 more pixels than before. Filling a game with content is a long and tedious task; it's best to make it as easy as possible.

I know, yesterday I had to recompile my script 4 times to get the proper heading for an NPC :D But it's usually not that bad.

Quote: Original post by Nemesis2k2

Quote: - Harder to make changes on the fly and keep them persistant (see my inbuilt script editor above)

Not sure what you mean by "persistant".

Well, this does depend on how far you want to go but you could as i say have a small inbuild system to edit scripts on the fly in the game and change things as they go, then its a small matter if writing that script back out to the file so that next time you run it again the change will have persisted (tbh, i'm not sure i'm spelling that right) between the runs.

Quote:
I disagree. Programming is programming. If you understand the syntax, the same issues exist between pretty much all languages. He could just as easily cut and paste some C code as Lua.

As others have pointed out not strickly true, I wouldnt expect a mapper/level designer to have an understanding of C or C++ let alone have a compiler for it, so asking them to make the changes on their own is a bit much when compared to the easy they could make a few trivial changes to a script and go from there.
Heck, you could even have the scripts constructed by a GUI as part of a map editor for example, cant easierly do that with C++ without the end user having a compiler already.

at the end of the day, its upto you todo what you want todo however it doesnt have to be an all or nothing gig, you could allow for both interfaces into the system, it probably wouldnt be that hard todo, so for the bits that need the speed you could step into C++ but for other things scripting will do for ya, much like the Unreal Engine allows.

Quote: garbage collection, function prototyping, header files, C strings, structures, memory allocation, etc

-Don't know enough about garbage collection to comment (but the fact is I can use C without knowing about it.
-The same issues exist for function prototyping in Lua as in C.
-How hard is it to write one line (eg, "#include <gamesdk.h>") and just accept it has to be there? People who understand headers can use them, people who don't don't have to.
-Strings I agree could be cumbersome.
-Structs I see as an essential high level construct. Structs are perfect for a message system for example, which is what I'll be using. The syntax is simple anyway.
-You don't have to use the higher level memory allocation stuff like new and delete if you don't want to, just like most of the other features of the language.

Quote: Scripting is there to decrease the development time of the game, whether it be for the lone developer or for a full-fledged modding community. How often do you fire up a compiler for something a simple sh script could do?

A fair point.

Quote: Scripting languages allow you to target in on what you are doing, as opposed to worrying about messy syntax or something or other. Scripts are meant to be straightforward and simple, as opposed to writing a quicksort function or a GUI system. With scripting, it's things like move character left 2 tiles; have them say this and that; if they have this item then do this. Scripting is perfect for this.

That is another example of something that would be a function anyway.
"MoveCharacter(LEFT, 2);"
Simple enough for me.

Quote: If you think that coding in C is the same as coding in Python, you've obviously never coded in Python. I've written things so fast in Python it makes my head spin. And it's easy to say right now "Oh, a recompile will take a little time but it's not bad" you'll be reconsidering that when you're trying to figure out the perfect animation delay for a sprite. Or getting a character to walk over 3 more pixels than before. Filling a game with content is a long and tedious task; it's best to make it as easy as possible.

No, I've never used Python. I have experience with Lua and a few scripting systems derived from basic and C. As for the compile time, It's like, one second. It takes you that long to switch between your script and your game anyway. Hit compile, and by the time your game tries to reload it, it'll be there.

Quote: All of this doesn't matter if you are writing a PacMan clone or an RPG with a town and a cave. But any semi-large-scale project will be well worth the time looking into a scripting language. I guess the best way to find out is experience though.

I'm making a large scale project. Quite large in fact. We're expecting another 2-3 years of development time. Still, I spent a long time thinking about this, and I couldn't see a good justification for a true scripting language over this system. I went through a whole notepad on this scripting thing alone, looking at it from as many angles as possible with as many cases as possible, using as many systems as possible. I settled on this one.

hey guys,

im working on a 2D RPG w / C++. i already posted this earlier, but i have a decent amount of the core engine done, i can make maps and link them all togeather, so i can basically make a world and walk around in it. now i just have to fill this world with content.

could someone explain to me the theory behind integrating scripting into the game? im planning on most likely using python if that matters. basically, this is what i dont understand:

which task's are left for scripting and which is for the C++ ? i would think all NPC interactions and world interaction should be left for scripts. (ie talking to NPC's or cut scenes or openeing a chest or something) but i just dont understand how to mix the Python w / C++. i mean, wont C++ have to do all the rendering? so i would have to switch back and fourth, having Python decide what to render, and telling C+/ OGL to render it? thanks for any help!!

Quote: Well, this does depend on how far you want to go but you could as i say have a small inbuild system to edit scripts on the fly in the game and change things as they go, then its a small matter if writing that script back out to the file so that next time you run it again the change will have persisted (tbh, i'm not sure i'm spelling that right) between the runs.

Ah yes. Each instance of a Script object has its own memory pointer. Variables that are needed to remain persistant are defined in a struct, which that pointer referances. Any variables that are needed to remain persistant are defined in the struct. On an Initialise message, the memory is mapped back to the pointer if it is wanted for that script. Its neater than it sounds.

Quote: As others have pointed out not strickly true, I wouldnt expect a mapper/level designer to have an understanding of C or C++ let alone have a compiler for it, so asking them to make the changes on their own is a bit much when compared to the easy they could make a few trivial changes to a script and go from there.

In my team, that isn't an issue. The person mainly responsible for level design knows the basics of both C and Lua, and prefers C. I can see how that might be an issue for some people though. Quite frankly though, programming in anything, be it Lua, Python, or C, requires knowing how to program. If the level designer knows how to program, the question is what languages do they know? More people know the basics of C than scripting languages like Lua and Python IMO, even level designers.

Quote: at the end of the day, its upto you todo what you want todo however it doesnt have to be an all or nothing gig, you could allow for both interfaces into the system, it probably wouldnt be that hard todo, so for the bits that need the speed you could step into C++ but for other things scripting will do for ya, much like the Unreal Engine allows.

I had thought about allowing for both scripts and DLL's. It would be easy enough to extend the system to allow for that functionality, but I've decided not to attempt it at this stage. I could always come back and implement that functionality in the engine, but its not a priority, and there's a lot of other stuff that needs to be done. I'd need to spend more time making sure there wouldn't be any difficulties with inter-script communication to make sure it would work with the current design though.

Quote: Original post by paradoxnjIf you want to change the way an enemy character behaves, you change the script and just restart the game.

Why bother restarting the game? Change the code and hit a button to reload the script. That's all.

There are other uses for a scripting language as well. File IO sucks in C/C++, but Python's IO is very powerful indeed. For example, writing a .OBJ importer in C++ is an easy but time consuming task. In python you can do it in a few lines with regexps. Native XML handling likewise. Can't be bothered writing a save game routine? Just send the data to Python and pickle, then loading just becomes the reverse. I'm using Python as an example here of course.

Quote: There are other uses for a scripting language as well. File IO sucks in C/C++, but Python's IO is very powerful indeed. For example, writing a .OBJ importer in C++ is an easy but time consuming task. In python you can do it in a few lines with regexps. Native XML handling likewise.

I think features like that are a bit beyond the scope of what you'd need for some basic game scripting.

Quote: Can't be bothered writing a save game routine? Just send the data to Python and pickle, then loading just becomes the reverse. I'm using Python as an example here of course.

I think that would be significantly harder than a cascading "save" function down your scene graph.