Scipting Language Choices (angelscript discussion)
![Post Post](./styles/qsilver/imageset/icon_post_target.gif)
This thread is a separation from an issue that arose out of viewtopic.php?f=35&t=5352
In the current situation, as I understand it, a version of angelscript source is bundled with opendungeons and used for the console menu; whilst a c++ version is commented out elsewhere. I assume this code to be functional although I have not checked this, but in terms of effort, it would be less then an hour to restore the old version and work from that.
In a much broader sense however, the question asires, what would we want in a script language for opendungeons? Generally speaking, the advantage of a scripting language comes from having these parts more easily accessable and due to their interpreted nature, do not require a long recompilation process in order to debug.
From what I understand, at the moment we use Angelscript; a "C without pointers"-like language which creates a console. There are, however, other aspects which may benefit from being scripted. A natural target may be general AI management and "scripted events" thoughout levels which trigger when certain conditions are met. And though I'm taking a stab in the dark, I would think animation may also fall in this catagory.
Another advantage of using a higher level language for certain parts of the codebase could be an potentially increased development pool, though this is a double edged sword, because if badly managed, the codebase may requre a dev to know both the scripting and the compiled parts of the code.
Parts of this may already be discussed, in which case I humbly request to know the outcome. Nevertheless, we are at a stage at which we can still easily reconsider our choice of angelscript. To steal and twist a few lines of bertram:
Angelscript:
- The Angel Scripting version bundled in the repo is starting to be old.
- It might be cluttering only and we might want something we're more at ease with.
+ AS is fitting for game scripting, as it is used, for instance in Overgrowth, for one.
+ The bindings are there, and ready to be completed.
+ Some example of porting is actually done. The console command porting is IMHO not the best area to use AS, but we can use that to get inspiration for other use.
+ The AS version bundled was made sure of being compilable both on Windows and Linux, at least to me. Several projects do import deps code when using sensible dependencies, so I understand the move here.
There are plenty of other options for anyone who cares to mention them. I will attempt to sum up python:
- can become complex when classes/threading/other random python is used.
+ has been proven usable in civilization 4
- performance of prime example wasn't really that great
+ probably known by blender users as it is used as blender scripting
Lua, from what i understand is more or less the arch-game-scripting language, of which examples would probably not be hard to find. Nevertheless, as I am unfamiliar with it I cannot sum it up more thoroughly. All in all, the choice depends on what we want to do with it, which this thread exists for to find out.
From bertrams' list I have taken out one of the 'cons': "It could be put as an outer dependency" and will now attempt to derail my own thread in the very first post. I would suggest that this should be done regardless of our choice. I would have no objection to us keeping a copy of upstream available separately, and bundling in with compiled code, but including it as it is done now is very hard to keep in sync correctly. Inevitably; it will drift apart from mainline and we would essentially have our very own scripting language to maintain. I would also like to broaden this suggestion to everything in the dependencies directory. Though we may still fall behind when we decide to not upgrade to a newer version when it arrives, this would be much more clear then when there happens to be a dependency directory with source.
In the current situation, as I understand it, a version of angelscript source is bundled with opendungeons and used for the console menu; whilst a c++ version is commented out elsewhere. I assume this code to be functional although I have not checked this, but in terms of effort, it would be less then an hour to restore the old version and work from that.
In a much broader sense however, the question asires, what would we want in a script language for opendungeons? Generally speaking, the advantage of a scripting language comes from having these parts more easily accessable and due to their interpreted nature, do not require a long recompilation process in order to debug.
From what I understand, at the moment we use Angelscript; a "C without pointers"-like language which creates a console. There are, however, other aspects which may benefit from being scripted. A natural target may be general AI management and "scripted events" thoughout levels which trigger when certain conditions are met. And though I'm taking a stab in the dark, I would think animation may also fall in this catagory.
Another advantage of using a higher level language for certain parts of the codebase could be an potentially increased development pool, though this is a double edged sword, because if badly managed, the codebase may requre a dev to know both the scripting and the compiled parts of the code.
Parts of this may already be discussed, in which case I humbly request to know the outcome. Nevertheless, we are at a stage at which we can still easily reconsider our choice of angelscript. To steal and twist a few lines of bertram:
Angelscript:
- The Angel Scripting version bundled in the repo is starting to be old.
- It might be cluttering only and we might want something we're more at ease with.
+ AS is fitting for game scripting, as it is used, for instance in Overgrowth, for one.
+ The bindings are there, and ready to be completed.
+ Some example of porting is actually done. The console command porting is IMHO not the best area to use AS, but we can use that to get inspiration for other use.
+ The AS version bundled was made sure of being compilable both on Windows and Linux, at least to me. Several projects do import deps code when using sensible dependencies, so I understand the move here.
There are plenty of other options for anyone who cares to mention them. I will attempt to sum up python:
- can become complex when classes/threading/other random python is used.
+ has been proven usable in civilization 4
- performance of prime example wasn't really that great
+ probably known by blender users as it is used as blender scripting
Lua, from what i understand is more or less the arch-game-scripting language, of which examples would probably not be hard to find. Nevertheless, as I am unfamiliar with it I cannot sum it up more thoroughly. All in all, the choice depends on what we want to do with it, which this thread exists for to find out.
From bertrams' list I have taken out one of the 'cons': "It could be put as an outer dependency" and will now attempt to derail my own thread in the very first post. I would suggest that this should be done regardless of our choice. I would have no objection to us keeping a copy of upstream available separately, and bundling in with compiled code, but including it as it is done now is very hard to keep in sync correctly. Inevitably; it will drift apart from mainline and we would essentially have our very own scripting language to maintain. I would also like to broaden this suggestion to everything in the dependencies directory. Though we may still fall behind when we decide to not upgrade to a newer version when it arrives, this would be much more clear then when there happens to be a dependency directory with source.