C
Chiffon
Guest
What is difference? using scripts & non-scripts?
I know we can make more epic character moves and awesome items with scripts.
I know we can make more epic character moves and awesome items with scripts.
Non script commands are predetermined behaviors already coded into the engine that either happen by default or you control with some degree using text commands. They are easy to use because the work has been done for you. Deplete an opponent's hit points and he falls down, flashes and disappears. Unless you want completely different behavior, you don't have to worry about how any of that stuff works.
The disadvantage is there is no way we as developers can code every last thing an author might want to do. What if you have certain stages with a water background, and you wanted certain kinds of hits to send that guy flying into it? How do you get him into the inaccessible background, but only for water KOs? How do you make him disappear with a splash precisely on landing? What do you do about areas without water or obstacles in the way? How do you decide which attacks can do the job without piling up dozens of strike types? How do you tell the engine which stages any of this can happen in at all?
Advanced grappling (pile driver moves, counter throwing, etc.) is another and perhaps the most profound example. There are simply too many options and parameters that need to be considered, especially once you get into "if this X happens, then do this, but if Y happens do that instead".
This is where script comes into play. Script is essentially inserting custom engine code right into your module. The advantage is two fold. The first is it allows you as an author to do whatever you want. If there is a gameplay feature you would like to see, it can be added - no matter how out there the concept might be. The other advantage is it helps keep the engine light and more portable. Instead of adding more and more arbitrary features that only work one way and take up space even when not in use, we as devs can can concentrate on making the core engine more efficient and the scripting interpreter ever more powerful.
The disadvantage of script is that you have to script. It's frustrating for people who are not used to the idea, an doubly so for those who don't understand the concept of thinking like a computer (though the latter applies to core commands as well).
If you want to put advanced logic into your module though, that's just the route you're going to have to take. Non scriptwriters asking for logic based concepts "without script" must understand that logic statements are exactly what script is. Adding core commands that do the same thing would be effectively inventing our own coding language - which as you might guess would be a ludicrous undertaking.
Fortunately there are enough modules now that utilize scripting and enough authors that know their way around script that now (as I had hoped a few years back) scripts can be passed around to share and insert. It IS a steeper learning curve, but it's also what has allowed OpenBOR to grow from poor cousin compared to engines like Mugen into a what is now arguably the single most powerful and versatile 2D sprite engine on the planet.
TL;DR: Stop being lazy and read. Anyway, non script commands are predetermined engine behaviors you can easily set up to make a basic module. Scripting is inserting your own engine code to make it behave exactly how you want.
DC
The disadvantage is there is no way we as developers can code every last thing an author might want to do. What if you have certain stages with a water background, and you wanted certain kinds of hits to send that guy flying into it? How do you get him into the inaccessible background, but only for water KOs? How do you make him disappear with a splash precisely on landing? What do you do about areas without water or obstacles in the way? How do you decide which attacks can do the job without piling up dozens of strike types? How do you tell the engine which stages any of this can happen in at all?
Advanced grappling (pile driver moves, counter throwing, etc.) is another and perhaps the most profound example. There are simply too many options and parameters that need to be considered, especially once you get into "if this X happens, then do this, but if Y happens do that instead".
This is where script comes into play. Script is essentially inserting custom engine code right into your module. The advantage is two fold. The first is it allows you as an author to do whatever you want. If there is a gameplay feature you would like to see, it can be added - no matter how out there the concept might be. The other advantage is it helps keep the engine light and more portable. Instead of adding more and more arbitrary features that only work one way and take up space even when not in use, we as devs can can concentrate on making the core engine more efficient and the scripting interpreter ever more powerful.
The disadvantage of script is that you have to script. It's frustrating for people who are not used to the idea, an doubly so for those who don't understand the concept of thinking like a computer (though the latter applies to core commands as well).
If you want to put advanced logic into your module though, that's just the route you're going to have to take. Non scriptwriters asking for logic based concepts "without script" must understand that logic statements are exactly what script is. Adding core commands that do the same thing would be effectively inventing our own coding language - which as you might guess would be a ludicrous undertaking.
Fortunately there are enough modules now that utilize scripting and enough authors that know their way around script that now (as I had hoped a few years back) scripts can be passed around to share and insert. It IS a steeper learning curve, but it's also what has allowed OpenBOR to grow from poor cousin compared to engines like Mugen into a what is now arguably the single most powerful and versatile 2D sprite engine on the planet.
TL;DR: Stop being lazy and read. Anyway, non script commands are predetermined engine behaviors you can easily set up to make a basic module. Scripting is inserting your own engine code to make it behave exactly how you want.
DC