Is Scripting For Me
I need a bit of advice in regards to wether I should script anything in my current project, and this seems like th ebest place for the job. Im creating a space RTS, something along side HomeWorld would be the best anology, but without the ability to build units etc during battle (you start with a pre-defined force, and thats your lot). Currently, all the units/contruction buildings (that u use outside of battle), the galaxy map, and game text are created in my custom built editor. You define a new unit (name, texture, model, stats etc.) and this is added to the list of units, which is then compiled into a units.rul file, which I load in when the game starts. This is the same for the the buildings and the text etc. My question is, would i be advised to use scripting here at all, or am i sort-of using scripting through my engine? I admit I dont really understand scripting (having only spent the last few hours reseraching it, and watching TV!). I understand scripting may be benificial for AI, but again, the AI stats of the units will be (when i get round to it) defined in the editor. Any advice on this would be appreciated, as at the moment im going down the "I dont need any scripting" route, and dont want to regret it at a later date. There will be no fancy cut scenes in this project (which is something i do understant the benifits of scripting would help with), just the player, playing the game against the AI. Thanks for any advice you might give CreamShabang
If you want to be able to modify the behavior of your program without recompiling the entire source, then scripting may be for you.
Essentially, with your editor, you are using your own form of scripting. You are editing stats and saving them to a file, which are loaded and interpreted by your engine.
The only place I would really look into is the AI...but if you make it modular (loaded .DLL or something), then I see no reason to go the scripting route. You probably want to make the AI run as quickly as possible, and scripting may just bog you down.
Essentially, with your editor, you are using your own form of scripting. You are editing stats and saving them to a file, which are loaded and interpreted by your engine.
The only place I would really look into is the AI...but if you make it modular (loaded .DLL or something), then I see no reason to go the scripting route. You probably want to make the AI run as quickly as possible, and scripting may just bog you down.
There is the age-old debate of scripted events vs. declarative events.
In some respects, declarative event triggering is easier - you don't need to be a programmer to use it. Implementing it MAY be easier. You won't need to embed a scripting engine.
On the other hand, not having scripts mean that certain things are not possible, or have to use extreme kludges. If you have to do something special for an end-of-game badguy or something, don't bother embedding a scripting engine, just hard code some weird piece of declarative logic instead.
For example, lots of earlier games such as DOOM, were entirely done declaratively, that's to say, various action types and IDs were placed on objects to trigger events.
More modern ones tended to use scripts, or a combination of declarative logic / scripts.
Declarative logic is much easier to visualise within a GUI editor, so if the people creating the logic are going to be using a GUI editor, it's got advantages. For example, if your game has doors and switches, you could highlight the doors which open when the user selects a switch.
Mark
In some respects, declarative event triggering is easier - you don't need to be a programmer to use it. Implementing it MAY be easier. You won't need to embed a scripting engine.
On the other hand, not having scripts mean that certain things are not possible, or have to use extreme kludges. If you have to do something special for an end-of-game badguy or something, don't bother embedding a scripting engine, just hard code some weird piece of declarative logic instead.
For example, lots of earlier games such as DOOM, were entirely done declaratively, that's to say, various action types and IDs were placed on objects to trigger events.
More modern ones tended to use scripts, or a combination of declarative logic / scripts.
Declarative logic is much easier to visualise within a GUI editor, so if the people creating the logic are going to be using a GUI editor, it's got advantages. For example, if your game has doors and switches, you could highlight the doors which open when the user selects a switch.
Mark
Sounds like you're already using scripting, albeit your own custom one. Scripting langs, especially ones like Lua and Squirrel are ideal for multiple uses. I tend to use them both for scripting, and for definition of stuff like units. Saves a good bit of time since I only have to write one binding/interop layer, and then I can use it for pretty much everything without having to worry about bugs in my unit loading code. The nice thing about the above mentioned langs is you can have as many state objects as you like. So you can have one for loading units, another for the console, etc. So you don't have to worry about someone hacking around with the unit definitions at runtime through the console.
Scripting is just an advanced form of a good practice called 'data driven design'. All that means is that instead of coding everything into the executable, the program uses outside data to guide it's behavior. It sounds like you already have all the data you need with a nice editor to edit the data. A script would be the same thing, only more robust (meaning it can do more stuff). If the data you have already is enough to do everything you need, there is no reason to scrap it all and pull out a more heavy duty type of data (script code is data just as much as your units.rul file) to do the job.
You should probably look into scripting sometime in the future, because someday you might need that level of flexability, but if what you have works well enough for you now, there is no need to change it just for the sake of changing it.
You should probably look into scripting sometime in the future, because someday you might need that level of flexability, but if what you have works well enough for you now, there is no need to change it just for the sake of changing it.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Ok, i def feel better about my use of the editor for unit definitions etc. I think I would rather stick with that since the editor is actually quite nice to use (I'm starting to like forms quite a lot ;)), and from what I can gather i would only get very similar results from scripting that part of the project anyway.
Edit: Having said that, I could alter the editor so it generates not a units.rul file, but instead the .lua file to define the units data. That way the easy front end of the editor could be used, while still having the robustness of scripting when loading in and reading the data...
But what about the use of scripting for AI? This is where i seem to be a bit lost. As was mentioned in a post linked the the forum FAQ, there is a lot of how to use... scripting languages, but very little on their pratical implementations.
How is scripting used to affect the AI. For example, I assume code regarding lines of sight, shooting, retreating etc is all coded in C++ (or what ever your language of choice is), but is the overlying AI logic (when to do line of sight, when to attack, when to run) all done in a script? Does the script just call particular game code as and when it sees fit, and it is through that that the AI can be modifed easily?
I was unaware that Lua had case statements (though i suppose you could do bih if else statements?), so could u create some kind of FSM through scripting, or is this what scripting would avoid?
Thanks for the advice so far... Its been more than helpful
CreamShabang
[Edited by - creamShabang on December 17, 2004 1:37:07 AM]
Edit: Having said that, I could alter the editor so it generates not a units.rul file, but instead the .lua file to define the units data. That way the easy front end of the editor could be used, while still having the robustness of scripting when loading in and reading the data...
But what about the use of scripting for AI? This is where i seem to be a bit lost. As was mentioned in a post linked the the forum FAQ, there is a lot of how to use... scripting languages, but very little on their pratical implementations.
How is scripting used to affect the AI. For example, I assume code regarding lines of sight, shooting, retreating etc is all coded in C++ (or what ever your language of choice is), but is the overlying AI logic (when to do line of sight, when to attack, when to run) all done in a script? Does the script just call particular game code as and when it sees fit, and it is through that that the AI can be modifed easily?
I was unaware that Lua had case statements (though i suppose you could do bih if else statements?), so could u create some kind of FSM through scripting, or is this what scripting would avoid?
Thanks for the advice so far... Its been more than helpful
CreamShabang
[Edited by - creamShabang on December 17, 2004 1:37:07 AM]
You pretty much have it figured out: The typical script (for anything, not just AI) calls a lot of high-level functions built in the native language (c++ or whatever you're using) and then uses some kind of logic to figure out what to (using a FSM in your example) and then calls more high level functions to actually do stuff. A psuedocode(using indentation for blocks) example might be something like
Which would be a simple script to make an enemy chase and attack the player if it has high enough health, or avoid the player and wander around outside the player's attack range if it has low health. Notice how the script has tons of logic, but nothing that might be complex (like updating the world with movement info) is directly handled by the script (the distance function might or might not be scripted depending on many factors)
My.VisibilityRadius = 100...if(IsVisible(My.VisibilityRadius, Player)) if(My.Health > My.MaxHealth * 0.5) if(DistanceTo(Player) > My.AttackDistance) MoveToward(Player.Position, My.MoveSpeed) else Attack(Player, My.Weapon) else if(DistanceTo(Player) < Player.AttackDistance * 3) MoveAwayFrom(Player.Position, My.MoveSpeed) else MoveInDirection(RandomAngle(), My.MoveSpeed / 3)
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Quote:
Original post by creamShabang
But what about the use of scripting for AI? This is where i seem to be a bit lost. As was mentioned in a post linked the the forum FAQ, there is a lot of how to use... scripting languages, but very little on their pratical implementations.
Mostly because the practical implementations depend greatly on how you plan to build your AI.
Quote:
How is scripting used to affect the AI. For example, I assume code regarding lines of sight, shooting, retreating etc is all coded in C++ (or what ever your language of choice is), but is the overlying AI logic (when to do line of sight, when to attack, when to run) all done in a script? Does the script just call particular game code as and when it sees fit, and it is through that that the AI can be modifed easily?
That's it more-or-less. The idea is to have the busy-work in c++, and the decision making in script.
Quote:
I was unaware that Lua had case statements (though i suppose you could do bih if else statements?), so could u create some kind of FSM through scripting, or is this what scripting would avoid?
It has something even better than switch statements... tables! If you're going to do, say, a simple state-based AI, you could have an ai table, and within that, a multitude of states:
// aggressive_ai is a table with several states defined elsewhere, perhaps// in /ai/aggressive.lua, and loaded in with all the other lua files in /ai/// on startupfighter.ai = aggressive_ai// now when we want to access a statecurrent_state = "attack"fighter.ai[current_state].doSomething();
Thanks guys, im definatly thinking of now going down the route of scripting for this project. Im not to bothered that it means re-writing large chunks of code, if i get something out of it at the end its all good :)
Obviously i need to have a good look at how lua works (i think ill go with that as I have a lot of documentation on it now!), but I have downloaded a few opensource games that use lua and im trawling through the code as we speak!
Thanks for the help guys
creamshabang
Obviously i need to have a good look at how lua works (i think ill go with that as I have a lot of documentation on it now!), but I have downloaded a few opensource games that use lua and im trawling through the code as we speak!
Thanks for the help guys
creamshabang
Markr meant hard-coded instead of declarative. Hard coded as in compiled into the source.
Declarative is a paradigm of programming where you declare constraints to the problem domain and allow the computer to hunt for solutions as in Prolog.
Declarative is a paradigm of programming where you declare constraints to the problem domain and allow the computer to hunt for solutions as in Prolog.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement