Archived

This topic is now archived and is closed to further replies.

iaretony

Radical thoughts on in game scripting...

Recommended Posts

I have recently read a number of articles on gamedev on the subject of "in game scripting". All of these articles describe how to build you''re own mini-programming language, complete with variables, loops, functions, conditionals, stacks and other scripting goodies... My problem with all this is that I don''t see the advantage. Aren''t you building a language that is just as complicated as C? If the answer is that I am supposed to build higher level functionality from the low level instructions these languages provide, I ask where the advantage over C comes from? Because I can do the EXACT same thing their... It seems that at the atomic level, these languages even DO the same things... I was expecting a higher level language with instructions that made sense for games... Sure, I could code the AI for my new NPC with my fancy schmancy scripting engine, but I could also just code it in C... A language that anyone can go to the bookstore and buy a million books about... I hope this doesn''t sound too harsh, I really want to know... What are the advantages? Has anyone ever thought about inventing a programming language with instructions that actually make sense for games? Tony

Share this post


Link to post
Share on other sites
C has to be compiled and linked, it is not a scripting language. In other words, it all has to be evaluated before it can run.

A scripting language is interpreted, in other words it runs as it is evaluated.

You *can* design your app so others can code add-ons for your app in C. That''s how .dll plug-ins work. But they will need a compiler (or you will need to provide one).

Share this post


Link to post
Share on other sites
You can make a high level scripting language. For example, using Lua in my engine I can do:

Camera:SetViewport(0, 0, width, height)

I know it''s not incredibly high level but I could do something like:

Player:Goto("Home Village")

if I wanted. It all depends on what functionality and APIs you expose to your scripts. But there has to be a (technical?) limit to high you can or want to go.

Share this post


Link to post
Share on other sites
iaretony -

I too have read a number of articles lately, both here on gamedev and around the net. I must say I do so with a lot of interest.

I think you might be missing what the goal of scripting languages is. It isn''t to make a language that is easier to use than the lower level scripting engine language. This may be a pleasant side-affect but really the advantages come in terms of development time. Once you get the scripting engine done, your development time is drastically cut by many factors...

1. As you noted, it is a "mini-programming language" so it is, for all intents and purposes, a subset of the functionality that the lower level engine provides.

2. Script is just easier to write, take internet development for example. You could encapsalate your functionality into a COM component, or you could use the components already set up for you and write a script in ASP. (Same goes for CGI/PHP).

3. The ideal script engine would obfuscate the really difficult parts of your program. Like loading models, drawing polys, performing the ai algorithms. You''ve just exposed an interface where the end user does not need to know how it works, but just that it does.

4. You are free to create a script language that is game specific, the tutorials that I think we''ve both read just get you started - it''s up to us to take it further. For instance maybe make a script function like loadModel("modelfilename.txt") or createNPC(npcType, behaviorDefinition, etc...).

All of these things will quicken the dev time, and all of these things are now NOT hardcoded into your program providing for the ideal platform for reuse.

I''m not sure how well I''ve expressed my view of it, but the bottom line is that scripting isn''t supposed to rid you of the syntax, and the difficulties inherent in programming, it is more to quicken development time, and to provide for extensibility and reuse.

random.

Share this post


Link to post
Share on other sites
I think you need to ask yourself this question: do I need to give users the flexibility of a certain level of control for the core of the program. If so: on which level? In my opinion (for games): a console with a basic command set is more then enough. This doesn''t include looping and iterations, but only simple things like:

set screenres 640 480
echo Hi mom!
cls
loadmap map-2
sound setvolume 256
sound setoutput directsound
...

If you need to write somekind of modifiable artificial intelligence or particle effects program, a scripting language could come in handy.

"My basic needs in life are food, love and a C++ compiler"
[Project AlterNova] [Novanet]

Share this post


Link to post
Share on other sites
1) The main advantage of a scripting language is that it allows you to change the parameters and behavior of your program without having to recompile it - that makes development quicker and less error-prone, since you''re not touching the code for every little thing.

2) Another advantage on a team is that artists and other non-programmers can work with the scripts to add to and adjust the game, without having to get developers involved, and again without the error-prone risks of touching the code.

I have just very simple scripts for my engine - really just a list of parameters for terrain, lists of meshes to load and their positions, etc. It is extremely quick and easy for me to adjust lighting, positioning, heights, etc. - all without risking anything by altering the c++ code.

I don''t have any logic. Though I can see how an AI script might need conditionals and loops and such. Scripts are very valuable - once your engine code is stable, you don''t have to open it up - just work with the scripts.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What everyone has mentioned is true. But the most important part is REUSE.

Build the engine once and modify the game with the scripting language.

The more robust the scripting language the more reuse, customization, and tweaking is possible. All this without the expense of having to recompile.

There are trade-offs, of course. More scripting language, more overhead and more interpretation time.

Share this post


Link to post
Share on other sites
The point of scripting systems is to add code after the game is compiled. If a game''s every level''s AI was "hard-coded", how would users add new levels? They couldn''t. See the point?

Share this post


Link to post
Share on other sites
quote:
Original post by BriTeg
C has to be compiled and linked, it is not a scripting language. In other words, it all has to be evaluated before it can run.

A scripting language is interpreted, in other words it runs as it is evaluated.

You *can* design your app so others can code add-ons for your app in C. That''s how .dll plug-ins work. But they will need a compiler (or you will need to provide one).


This is a very good point. Scripting does provide end user extensability (sp?) that is cumbersome to accomplish in C. But this is just PART of why scripting languages are advocated. I do not dispute this part.

What I dispute is the usefullness of the language to the original developer.

Share this post


Link to post
Share on other sites
quote:
Original post by stodge
You can make a high level scripting language. For example, using Lua in my engine I can do:

Camera:SetViewport(0, 0, width, height)

I know it''s not incredibly high level but I could do something like:

Player:Goto("Home Village")

if I wanted. It all depends on what functionality and APIs you expose to your scripts. But there has to be a (technical?) limit to high you can or want to go.


This is close to what I was getting at. EXCEPT! What I would like to see developed is not a higher level API (set of functions that apply to the domain of a game), but a higher level LANGUAGE. I want the low level syntax of a language optimized for game creation.

For instance, what if their was a data type that represented a "game character"? What if their was an "NPC" character type?
Just like their is an "int" in C?

What if their was an inherant main loop, and every "game character" got some processing time every frame... I''m not trying to design the language here, I just want to advocate the exploration of something like this.

Share this post


Link to post
Share on other sites
quote:
Original post by random_acts
iaretony -

>I think you might be missing what the goal of scripting >languages is. It isn''t to make a language that is easier to >use than the lower level scripting engine language. This may >be a pleasant side-affect but really the advantages come in >terms of development time. Once you get the scripting engine >done, your

Wouldn''t a speed up in development time be the direct effect of a language that is easier to use?

>1. As you noted, it is a "mini-programming language" so it is, >for all intents and purposes, a subset of the functionality >that the lower level engine provides.

The articles that I have seen do not present a language that is a subset of an Engine, they present a language that is a subset of another language.

>2. Script is just easier to write, take internet development >for example. You could encapsalate your functionality into a >COM component, or you could use the components already set up >for you and write a script in ASP. (Same goes for CGI/PHP).

I can honestly say that I find writing C/C++ code easier than internet development. I have over 10 years experience writing C code, and it is what I am least likely to make an error using. I don''t really buy the idea that writing a script is inherantly easier than writing some C code. The ease of development depends entirely on the syntax of the languages, and the availability of good API''s.

>3. The ideal script engine would obfuscate the really >difficult parts of your program. Like loading models, drawing >polys, performing the ai algorithms. You''ve just exposed an >interface where the end user does not need to know how it >works, but just that it does.

This is better. I want more than an API tho. I want the language itself to be specific to the domain of GAMES. I want constructs within the language that solve game issues.

>4. You are free to create a script language that is game >specific, the tutorials that I think we''ve both read just get >you started - it''s up to us to take it further. For instance >maybe make a script function like loadModel("modelfilename.txt") or createNPC(npcType, behaviorDefinition, etc...).

All of these things will quicken the dev time, and all of these things are now NOT hardcoded into your program providing for the ideal platform for reuse.

I''m not sure how well I''ve expressed my view of it, but the bottom line is that scripting isn''t supposed to rid you of the syntax, and the difficulties inherent in programming, it is more to quicken development time, and to provide for extensibility and reuse.



random.


Share this post


Link to post
Share on other sites
quote:
Original post by SDyer
>1) The main advantage of a scripting language is that it allows >you to change the parameters and behavior of your program >without having to recompile it - that makes development quicker >and less error-prone, since you''re not touching the code for >very little thing.

This sounds more like an "ini" file to me. I do already use something like this in my games. But I don''t consider it a scripting language.

>2) Another advantage on a team is that artists and other non->programmers can work with the scripts to add to and adjust the >game, without having to get developers involved, and again >without the error-prone risks of touching the code.

This is actually an advantage I see mentioned quite a bit. But I question whether this is really true. If I create a language that has all of the things that make C "hard to use" then wouldn''t it be equivalent? Perhaps we decide that Pointers cause all of the problems in C, and we implement a scripting language without pointers for the artists and designers to use. Couldn''t we also just have removed the ''*'' from their keyboards and let them do it in C? Or simply said "Dont do that!".

>I have just very simple scripts for my engine - really just a >list of parameters for terrain, lists of meshes to load and >their positions, etc. It is extremely quick and easy for me to >adjust lighting, positioning, heights, etc. - all without >risking anything by altering the c++ code.

I don''t question the usefullness of ini files.


Share this post


Link to post
Share on other sites
quote:
Original post by iaretony
I want the low level syntax of a language optimized for game creation.

For instance, what if their was a data type that represented a "game character"? What if their was an "NPC" character type?
Just like their is an "int" in C?

What if their was an inherant main loop, and every "game character" got some processing time every frame... I'm not trying to design the language here, I just want to advocate the exploration of something like this.


I really don't think that such a language will ever exist, it's too specific, and any thing that resembles it will more or less be a scripting system of some sort. While there are languages that are very specific, they seem to be (for the most part) interpreted, and could be described as scripts (SQL being the first to pop in my head). The closest you'll ever come is an object oriented C++ game engine or library. Where you could define a class called NPC ...

int main() {
int iCounter;
NPC * npcBadGuy;

npcBadGuy->xPos = 5;
npcBadGuy->yPos = 10;
npcBadGuy->zPos = 0;
npcBadGuy->type = "ogre";

...

return 0;
}

At this point though, what you're asking for has nothing to do with "game scripting" as described in your subject.

[EDIT] Realized that you'd be very hard pressed to create a language that is only for games because there is so much that goes into games that aren't thought of as "game specific" such as ai, gui, etc... even then having things layed out with game specific functions and such would make cookie cutter games, and prohibits the programmer from being creative and imagintive - which would take the "art" out of his/her code. Where's the fun in that?

[EDIT] Your argument seems to shift from post to post...hmmm...

[edited by - random_acts on May 27, 2003 5:25:20 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by iaretony
[quote]Original post by SDyer
>1) The main advantage of a scripting language is that it allows >you to change the parameters and behavior of your program >without having to recompile it - that makes development quicker >and less error-prone, since you''re not touching the code for >very little thing.

This sounds more like an "ini" file to me. I do already use something like this in my games. But I don''t consider it a scripting language.




hmm, di you ever consider generating script output in realtime and then plugging it in while its still hot?

i mean, in the game you could generate the gamflow online based on user interaction and generate scripts for that for example for future events, which you could feed back into your program...

besides you could protocol, rplay and so on...

daniel

Share this post


Link to post
Share on other sites
IareTony - yes, i use script mostly as an ini file right now - but the techniques I use are extensible to logic scripting.

In any event, you can certainly do whatever you feel is best and what you are most comfortable with. If you want to code everything, maybe with .dll plugins, that can certainly work. I learned a long time ago in programming that there is rarely a "standard" way of doing complex, app-specific things. Getting your program to do what you want it to do is the main thing.

Share this post


Link to post
Share on other sites