Scripting Engines
Author
Well I''m currently designing a 2D Tile bases engine using Direct Draw in C++. I''m a little stuck in getting my mind wrapped around the idea of what a scripting engine will do and even more how it will do it.
I''ve seen alot of posts where they say that Python is a good language to use for scripting, but after a quick look over the site it looks like its just its own language and it didn''t seem to show how to connect it to a c++ program.
also if I''m going to do scripting would I read the scripts from say (just to keep it simple) a text file?
I quess I''m just looking for a push in the right direction
Please visit Turt99 Productions
The documentation available on the site has a section dealing with extending and embedding. Using it within an application you do both. Extending is providing functions that can be called from the script. Embedding is calling scripts from your application. Generally to do anything useful the script needs to be able to call you back when you call it. An example is to get information about the current state of the game or some object within the game.
As far as how to use it that is pretty much in response to events. Some examples are OnAttacked, OnInjured, OnDisturbed, OnOpened, OnUse, OnAttemptAction. So using OnAttemptAction. The user tries to open a door so OnAttemptAction fires with the actor and the action. You have two ways to pass those parameters. One is literally as a parameter so the script has to be coded as a function taking parameters. The other is to just stick it in the variable pool as a predefined name. Either way the script attached to OnAttemptAction sees that the action is OpenAction, an action it recognizes, and it queries the actor''s inventory for a key with a specific id which may be an attribute of the door object in the game. So most doors in the game run the same script with the designer putting differant key ids in a field in the GUI. There might be another script that checks time of day, i.e. you can only open the door to the shop between 8AM and 8PM. So perhaps that field that had a key id now has a time range. Overall the script just returns True or False. Yes, this actor can perform this action on this object, or No, they can''t. If they can then you turn around and fire a OnAction event with the same actor and action. It runs the animation to actually open the door which may simply be setting an IsOpen flag on itself to True.
Basically it is just like Windows. You recieve events and your respond to them. You could dump a big burden on the user and make them figure out what event. So they have a script a thousand lines long handling every possible event. The point being that how you integrate makes a big differance. The example of a field that has the key id is a prime example. Having user defined fields on every object that can respond to an event makes code reuse a world easier. You cannot foresee every possible flag and value they might need to implement what they want to do. Chances are they don''t need more than five for a single object. Occasionally they might need a table though and five isn''t enough for that. So you tack on a text field as well. Python provides them the means to easily deal with that table once you give them the ability to get the data into the script.
Getting data into a script can be done in two differant ways. You can predefine variables or make the user call a function to fetch the variable into a local variable. There is a balancing act there. Every script starting with the same sequence of calls is cumbersome. Preloading a bunch of variables seldom used is a waste of time. To many predefined variable confuses the user. Parameters in provide a compromise. You simply provide a skeleton and they put there code between the brackets. The function definition simply serves as a reminder. Every script attached to an event has a this pointer for the object transitioning between states, i.e. receiving the event. Most likely every script needs to access the module. The reason for mentioning it though is that is part of calling a script. Providing the variable pool for it to use. Most scripts need some type of persistance. They need to be able to set a variable on one run and use it on the next. Python provide the syntax to promote a variable from the default local scope, but it is up to you to keep returning that same pool rather than recreating it.
That is logically all there is to it. There is a good deal more. Most of it is dealing with the variable pool. As an example when a user calls a function you provide you have to actually parse the parameters and extract them in the data type you want. Parsing here has a very precise defintion. It is not dealing with text. They have already been tokenized. Rather you are verifying that it is the correct number of parameters and that they have the correct type. That is an important point because even if within the script it looks like a call to the corresponding function in your program it isn''t. It is a call to an interface function that extracts the parameters in the correct type then turns around and calls the real function then formats the results so it can be returned through python. That is most of the real work involved in using python.
Integrating the script is a seperate task. That is truely the hard part. Figuring out how to empower the user with scripting support. Simply providing the user a means to organize their scripts so they can quickly find the right one alone can be a challenge. Also it is best not to let them run with the scripts. If you do then you end up with a huge code base and are stuck with cumbersome ways of doing things. Instead have them build a test level. The sole intent is to test the scripting system. Then review all the scripts in detail. Figure out how to do the same thing with both fewer and smaller scripts. There is always a way to do that and the time to do it is at the start, not the end.
As far as how to use it that is pretty much in response to events. Some examples are OnAttacked, OnInjured, OnDisturbed, OnOpened, OnUse, OnAttemptAction. So using OnAttemptAction. The user tries to open a door so OnAttemptAction fires with the actor and the action. You have two ways to pass those parameters. One is literally as a parameter so the script has to be coded as a function taking parameters. The other is to just stick it in the variable pool as a predefined name. Either way the script attached to OnAttemptAction sees that the action is OpenAction, an action it recognizes, and it queries the actor''s inventory for a key with a specific id which may be an attribute of the door object in the game. So most doors in the game run the same script with the designer putting differant key ids in a field in the GUI. There might be another script that checks time of day, i.e. you can only open the door to the shop between 8AM and 8PM. So perhaps that field that had a key id now has a time range. Overall the script just returns True or False. Yes, this actor can perform this action on this object, or No, they can''t. If they can then you turn around and fire a OnAction event with the same actor and action. It runs the animation to actually open the door which may simply be setting an IsOpen flag on itself to True.
Basically it is just like Windows. You recieve events and your respond to them. You could dump a big burden on the user and make them figure out what event. So they have a script a thousand lines long handling every possible event. The point being that how you integrate makes a big differance. The example of a field that has the key id is a prime example. Having user defined fields on every object that can respond to an event makes code reuse a world easier. You cannot foresee every possible flag and value they might need to implement what they want to do. Chances are they don''t need more than five for a single object. Occasionally they might need a table though and five isn''t enough for that. So you tack on a text field as well. Python provides them the means to easily deal with that table once you give them the ability to get the data into the script.
Getting data into a script can be done in two differant ways. You can predefine variables or make the user call a function to fetch the variable into a local variable. There is a balancing act there. Every script starting with the same sequence of calls is cumbersome. Preloading a bunch of variables seldom used is a waste of time. To many predefined variable confuses the user. Parameters in provide a compromise. You simply provide a skeleton and they put there code between the brackets. The function definition simply serves as a reminder. Every script attached to an event has a this pointer for the object transitioning between states, i.e. receiving the event. Most likely every script needs to access the module. The reason for mentioning it though is that is part of calling a script. Providing the variable pool for it to use. Most scripts need some type of persistance. They need to be able to set a variable on one run and use it on the next. Python provide the syntax to promote a variable from the default local scope, but it is up to you to keep returning that same pool rather than recreating it.
That is logically all there is to it. There is a good deal more. Most of it is dealing with the variable pool. As an example when a user calls a function you provide you have to actually parse the parameters and extract them in the data type you want. Parsing here has a very precise defintion. It is not dealing with text. They have already been tokenized. Rather you are verifying that it is the correct number of parameters and that they have the correct type. That is an important point because even if within the script it looks like a call to the corresponding function in your program it isn''t. It is a call to an interface function that extracts the parameters in the correct type then turns around and calls the real function then formats the results so it can be returned through python. That is most of the real work involved in using python.
Integrating the script is a seperate task. That is truely the hard part. Figuring out how to empower the user with scripting support. Simply providing the user a means to organize their scripts so they can quickly find the right one alone can be a challenge. Also it is best not to let them run with the scripts. If you do then you end up with a huge code base and are stuck with cumbersome ways of doing things. Instead have them build a test level. The sole intent is to test the scripting system. Then review all the scripts in detail. Figure out how to do the same thing with both fewer and smaller scripts. There is always a way to do that and the time to do it is at the start, not the end.
Author
Wow thank you for the detailed post, I think that was what I needed, I''m going to read up on that information as soon as I can
Please visit Turt99 Productions
Please visit Turt99 Productions
As far as where, it is a resource just like the tiles. You may be picturing one script, but you should picture hundreds of scripts. You will have a few scripts that do routine tasks. Say a script to check if the user has the right key attached to many differant objects all over the game. Most of the scripts though are the special cases. You have a hundred doors done exactly the same and then ten doors that are unique with each having it''s own script. So maybe 90% of the scripts seldom run and the other 10% are running constantly.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
