• Advertisement
Sign in to follow this  

How scripting works? (detailed)

This topic is 3511 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, i'm relatively new to game programming and find the concept of scripting very interesting. I'm currently attempting to learn more about it, and while i understand the macro concept of how scripting works i'm not able to work it out in my head just exactly how scripting for a game engine would work. Not so much how it would work computationally but where the scripts fit into the update, render loop. The guides on the internet that i have found seem to either assume a working knowledge of scripting languages or cover too general a topic and never get down to the gritty details of how it works. Any help, links or responses, would be much appreciated.

Share this post


Link to post
Share on other sites
Advertisement
The way I do mine is I have a Script Handler that loads all the scripts you wanna use for the current level. At first they are toggled all to off.

Then if they are flagged to run on startup or continuously they are turned on and as well they are turned on if they are called from an object.

Then each frame one line from each active script is executed and if the end of the script is reached then they are toggled to off.

Pretty simple psuedo-multithreaded idea. Got the idea from Tim Sweeny's ZZT game actually.

Hey another guy from the Pittsburgh Area, that's awesome.

Share this post


Link to post
Share on other sites
oh okay, so the game loop would just check the active scripts before each update/render cycle. thanks for clearing that up for me.


edit: go steelers

Share this post


Link to post
Share on other sites
Scripting is easier for semi-programmers to make use of/clone in regular patterns to fill in the object behavior/asset control in games. Its usually significantly slower than native code so should be used at a high level where the engine primitves it invokes do the costly detailed work.

A simple example is scripting used to coordinate animations and sound timing/transitions. Finite state machines written in the script stitch together the anmimation snippets and make the sounds play at the appropriate places to match the action patterns needed in the game (ex- a walking animation has a start and an end and a repeating pattern in the middle of indeterminant length and may have transitional animations for turning or flow in and out of other actions like jumps, etc...)

The game engine (written in fast native code) does the graphics and sound and the scripting coordinate those lower level calls and has the control logic for the high level sequencing.

For object 'intelligence' behavior the scripts might control decisions between different sequences of actions in response to the objects environment (if-then logic with thresholds and tests of various factors of the environment and the objects simulated internal state). Again AI doesnt have to be recalculated 1000 times a second but might only have to run once a second to redirect the behavior which is then executed by the animation scripting. The script is mostly waiting for the low level operations before having to decide the next course of action.

Most behavior in games is simple reaction in a choreographed terrain/prepositions scenes (where real AI with planning and simultaneous tasks and complex strategies can eat ALOT of CPU when they attempt to simulate more generalized adaptive behaviors).


An example of something you wouldnt write in the script languag would be something like the pathfinder which is computationally intensive. You would invoke it from the high level script, but most of the work is done by highly optimized native code.

Share this post


Link to post
Share on other sites
Quote:
Original post by mikesobczak
oh okay, so the game loop would just check the active scripts before each update/render cycle. thanks for clearing that up for me.


I think the idea of running one line per update is an unusual one (though it could work well, if you're careful). More common would be to run entire scripts on certain events, where events could include the object being created, being destroyed, being updated (ie. once per frame), being used, etc.

More advanced systems might use some notion of coroutines, which are basically like mini-programs that can pause at prescribed points and return control back to the application, then resume from the same point later when you ask. This allows for many scripts to appear to run concurrently while actually running one after the other.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
I think the idea of running one line per update is an unusual one


Thank you, yeah I read about ZZT's scripting and thought wow, what if I executed one line per script per frame and it worked relatively well.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement