Radical thoughts on in game scripting...
Author
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
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).
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).
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.
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.
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.
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.
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]
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]
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.
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.
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.
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.
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?
Author
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.
Author
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement