Scipting Language Choices (angelscript discussion)

Scipting Language Choices (angelscript discussion)

Postby nido » 14 Mar 2014, 02:01

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.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 14 Mar 2014, 09:45

Hi nido,

Thanks for the thread, :)

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.

The other dependencies are mostly there to ease the development on Windows, I wouldn't remove them simply for that, and why not make CMake check their system version counter parts on linux, for instance.
I hope we can agree on that. Compiling OD on Windows isn't that easy. ;)

As for me, I'd comfortable with using either Lua or keep using AS. What is your thought about this guys?

Best regards,
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby Akien » 14 Mar 2014, 10:55

Bertram {l Wrote}:
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.

The other dependencies are mostly there to ease the development on Windows, I wouldn't remove them simply for that, and why not make CMake check their system version counter parts on linux, for instance.
I hope we can agree on that. Compiling OD on Windows isn't that easy. ;)


Just some insight from a Linux packager: whenever it's possible, it's great to have a CMake build system capable of finding system-wide libraries and using them instead of the bundled ones. The less built-in dependencies, the happier distro developers are (because it's just impossible to patch security bugs in built-in libraries). It can be an automatic detection of existing library headers, or it can be an argument passed to CMake (e.g. -DUSE_SYSTEM_AS=ON).
Godot Engine project manager and maintainer.
Occasional FOSS gamedev: Lugaru, OpenDungeons, Jetpaca, Minilens.
User avatar
Akien
 
Posts: 737
Joined: 22 Feb 2014, 13:14

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 14 Mar 2014, 11:15

Seconded. I'm a former packager, too, after all. ;)
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby nido » 14 Mar 2014, 22:35

The other dependencies are mostly there to ease the development on Windows


The contents of the dependency folder is as follows:

dirent/dirent.h - extracted from the dirent package three years ago (v1.11 versus 1.13.2). Dirent was explicitly meant to be put in the system include directory, seems to have a bsd-like license. This file is the same as the original.

pthreads - a pthreads implementation advertising itself as Pthreads-win32 v2.8.0. The current (2012) release is 2.9.0. We actually only ship the header files and libraries. The binaries are equal to the ones delivered by upstream, the header files are not. Whilst this program does not change much; realise firsly we are actually maintaining our own pthread library header files. Also, this software is licensed under LGPL which compels us to also make the source available (though it could be argued we do when we link to the upstream code). It also compels us to include said license, which I have not found in our repository.

tinygettext - this is an interesting case. The package has been unmaintained since 2011 and I have been unable to devine a version number, so I have not compared our code to upstream expecially since I do know some projects have included it and other projects have copied their versions from other projects rather then upstream. With the package itself being in such a state of flux, for this one I understand best to include it as is.

libxml2 - has a license which compels altered files to be clearly marked as such. I have checked the first 1000 lines of the cpp and h file and did not notice any clear markings. However; the files are different from any version ever in the upstream repository.



For this very project, the art of verbatim copying into our repostitory resulted in 2 cases of outdated software (newer versions available), 2 license violations, and 2 cases of changes from upstream.

I do not know much about windows development, so I do not know well how this is organised as opposed to unix systems. Apparently, reading from dirent, there is a system include folder in which stuff could be. I presume OGRE and CEGUI (two prominent dependencies we do not bundle), are included from there.

As far as I know there is no software repository in windows where these kind of packages are "just there" and from what I understand, modus operandi involves having binary copies of your dependencies in you Program Files folder. I also understand that I cannot change that just because "I happen to not like it".

I do understand the convenience of having a single directory where you type make, or press a single button, and it 'just works'. The price for the current situation, is outdated and modified (thus implicitly maintained by us) software. Package managers aren't the only people who benefit from neat dependency management. (I, the software configuration guy, does too :p)

I also do not propose we remove the dependencies and leave it at that. Rather, I would like to propose we distribute a separate package, perhaps named 'opendungeons-dependencies.zip', which contain source, include headers, (windows) libraries and other helper files needed for these sorts of packages.

We could even expect this archive to be unzipped into a certain location within our source tree and have CMake act accordingly when it finds the files, so the only extra effort to be done is to unzip a zipfile if your system cannot satisfy the dependencies.
Doing this would clearly differentiate between what falls under 'opendungeons' responsibility, and what does not. We are already in a situation where including external dependencies in the source lead us to problems (maybe not big problems, but problems nontheless). Having dependencies managed separately from the opendungeons code itself will not make it impossible to still make changes to our dependencies, but it will be very clear that you are not editing dependencies and not opendungeons proper.

and why not make CMake check their system version counter parts on linux


Whether we stay as is, or go for the 'unzip extra file' method, is there a good reason to not use the system version on other systems? It makes sense to me to use the system version by default and only use the internal version when the system version is not available, or cmake is explicitly told to (by specifying the path to the library/include dir to use)





In order to also reply to the actual thread topic, I would like to consider where we would like to make use of a scripting language before we settle on one, or we may end up with one doing nothing.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 15 Mar 2014, 02:29

Hi nido, :)

Thanks for the precise answer upon all this.

We could even expect this archive to be unzipped into a certain location within our source tree and have CMake act accordingly when it finds the files, so the only extra effort to be done is to unzip a zipfile if your system cannot satisfy the dependencies.

Seconded. As long as you don't need that zip to compile on linux. This means we first have to adapt the CMake file to go grab system-wide counter parts, as a default, while still having the option to search the local files.

Could you make a precise list of eye-hurting files so we can decide what to put in the zip file?

As for me, we can get rid of tinygettext. Gettext can be used instead, since it got rid of the annoying bugs it has and is much more standard. Plus, it's not used much atm in OD.
We can also get rid of tinyxml, once paul will have something worth merging, we'll add back what's necessary regarding Xmls.

I don't know whether dirent.h is needed or provided on Windows. I'll have to check.
pthreads will have to be part of the zip, as for me.

As for the scripting language question, as for me, AS is fine to stay if everyone is ok about it. Whe should make sure it fits our needs in term of event and AI scripting at least.
If not, I'd propose Lua as I'm used to it and know how to do bindings with.

Best regards,
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby oln » 15 Mar 2014, 09:16

There just hasn't been anyone keeping the libs up to date for a while.

The code that uses dirent.h could probably be altered to use boost::filesystem, since boost is a dependency anyhow.
Since C++11 is used now, the code using pthreads could be ported over to use the C++11 thread library (I think that has been the plan anyhow), though that will probably be a bit of work.
Not sure if tinygettext is really used, so it should be easy to pick out or change for now.

As for angelscript, we originally decided to use it because it seemed to integrate nicely with c++ and easy to use. Though, it has been causing some compilation issues. Additionally we had issues using it as a library, rather than compiling it in, which makes packagers sad. So I think it could be worth considering a switch to something else seeing as it's not widely used yet. (I agree that there should be a scripting language though.)
User avatar
oln
 
Posts: 1020
Joined: 26 Oct 2010, 22:16
Location: Norway

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 15 Mar 2014, 12:27

Hi,

While on it, please read this:
viewtopic.php?f=35&t=5363

@oln:
Thanks for the precisions. They all make sense indeed.

- pthreads: To be replaced with boost::thread. Looks quite straight-forward. Just maybe not now as I'd like to get through the whole code once to clean it up a bit first,
and why not have a proper release copied in the master branch. Then, yes, it will be smarter. :)
- filesystem: Makes sense. Same comment than for pthreads.
- tinygettext should be removed for now, IMHO. (Doesn't work on Windows for instance), plus it's not really implemented anyway. We should remove the use of it and maybe later start on a proper replacement.
- AS/scripting language: I'll be honest. I'd keep it unless we can't really make this an outer library. But the version put there is old and from what I can see on angelcode.com, the problem with the use of it as a library are fixed or being fixed atm so I think we can keep it. Would we switch to lua, well, we'd lose quite some work, have to redo the bindings and test them and have other problems linked to lua, anyway.

As a first step, why not updating the used files and see if it is still working?

My two cents. :)
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby nido » 17 Mar 2014, 23:18

Could you make a precise list of eye-hurting files so we can decide what to put in the zip file?


Prime target would be "the dependencies folder". I would suggest this to be the path to which the file unzips to too.

we can replace X with Y

We can, but my problem is not so much with the packages themselves as it is the state they are in. The act of changing the source accordingly is not a trivial one.

As a first step, why not updating the used files and see if it is still working?

I would consider this a good idea regardless of separation. Nevertheless, I would suggest someone who uses the windows platform to perform said changes, as they are the primary stakeholders regarding these files.

I would love to discuss configuration implications via text or voicechat with the person in question as it would make sense to change the directory to signify the different types of files we include. That is, assuming there are no more objections to externalising these dependencies.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 18 Mar 2014, 09:25

We can, but my problem is not so much with the packages themselves as it is the state they are in. The act of changing the source accordingly is not a trivial one.

True, so I'd suggest, let's do it, but just not now. After we've got a healthy release in the master branch, thus after the development branch is fitting our scope for the next release. Let's not do everything at once, right? ;)

I would consider this a good idea regardless of separation. Nevertheless, I would suggest someone who uses the windows platform to perform said changes, as they are the primary stakeholders regarding these files.

True as well. I'll do it since it seems I'm the one compiling there. Yet, would someone provide me the link where I can find dirent.h and pthreads, it'd be a time savior.
Btw, as I am a dungeon critter, and made out of pure evilish magic, I will recklessly and bluntly slaughter the tinygettext and tinyxml files there. ;)
We'll add proper replacement when we'll truely use them.

I would love to discuss configuration implications via text or voicechat with the person in question as it would make sense to change the directory to signify the different types of files we include. That is, assuming there are no more objections to externalising these dependencies.

Sadly, I just don't have the time for that at the moment. Plus, what's written stays, and the forums are permitting me to look at what has been said weeks ago, which has proven being useful many times, and not only for this project. So, I'd rather have written-only communication, as for me.

Anyway, thanks for your help nido with all this stuff. :)
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby nido » 19 Mar 2014, 00:03

Bertram {l Wrote}:True, so I'd suggest, let's do it, but just not now. After we've got a healthy release in the master branch, thus after the development branch is fitting our scope for the next release. Let's not do everything at once, right? ;)

no problem. Did we not have a todo list somewhere to add this to? I shall look after posting.

True as well. I'll do it since it seems I'm the one compiling there. Yet, would someone provide me the link where I can find dirent.h and pthreads, it'd be a time savior.

since i was the one providing the information, allow me to reveal the source:
dirent: http://softagalleria.net/dirent.php
pthreads-win32: https://www.sourceware.org/pthreads-win32/
tinygettext: https://code.google.com/p/tinygettext/
tinyxml: http://www.grinninglizard.com/tinyxml/

Btw, as I am a dungeon critter, and made out of pure evilish magic, I will recklessly and bluntly slaughter the tinygettext and tinyxml files there. We'll add proper replacement when we'll truely use them. ;)


quoting from http://opendungeons.sourceforge.net/?q= ... guidelines: "Don't include everything only because you could need it in the far future, instead only include what you really need __now__."
Though this speaks about header file includes, i think it is a good idea to extend this to external dependencies as well. If they are indeed doing nothing, I see little reason to include them. Especially since there is such a multitude of alternatives which could also be used for the same purpose when we finally need something with their functionality.

Sadly, I just don't have the time for that at the moment. Plus, what's written stays, and the forums are permitting me to look at what has been said weeks ago, which has proven being useful many times, and not only for this project. So, I'd rather have written-only communication, as for me.

I would like to observe that text-chat (e.g. irc) is also written, but I see your point. I do not have a particular opinion about the point, and this is probably best discussed in a separate thread when such changes will actually be done.



which brings me back to this threads' main point: Angelscript and its future, or What will we do with scripting?

From my limited experience and observations, it seems that currently angelscript implements part of the console commands you get when pressing ~ (for example, possescreature is handled in c++), which allows you to enter a bunch of commands such as saving the game and controlling the camera.

Essentially, we're implementing a scripting language in a scripting language. Though this is not necesarily a bad thing. For one, the act of string comparing is not one of my favourite activities in c++.

The question is, where do we want to go from here. What do we want to do in which scripting? Why?

I would like to suggest to have campaign design in this top scripting language. This would include timers, hero dropping, creature altering, tile alterations not available to keepers. Decisions like where which creature gets dropped or does something special is very suspectable to rapid changes, and as such having this all the way in the c++ code would dampen speed development drastically. Also, in the in-game environment, one is able to try out locations or possibilities easily before deciding on a final script. perhaps such development could be aided (long term) by using mouse location or control in building these scripts (after all, who really cares about what position "that spot right there" is).

In relation to the above suggestion, it makes sense to me to have scripted versions of each control posibility of player keeper. Most of these will probably overlap, though keeper-specific actions may still allow for high level 'helper-ai' design and allows for a wonderful metagame of opendungeons-robots of battling user ai's.

Another place where scripting could be helpful would be game asset management. From what I understand, modelers create a model which is converted to some mesh, which is then programmatically added in c++ by developers. This is extrapolation of heresay so may be profoundly off mark. Still, I think it would be very useful if modelers could be able to include their designs into opendungeons without touching c++.


Rather then implementing a language which could do these things, a language could possibly be embedded to do this. Python will probably not be great targets for this, as i would fear for angelscript; though i am not sure about lua. Other languages may also exist which fit this position a lot better, though I am not able to name one. I would be happy to hear your ideas about this subject.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 19 Mar 2014, 11:39

Hi nido,

And thanks for the links! :)

I would like to observe that text-chat (e.g. irc) is also written

Yes, but it has got so many drawbacks coming from the spontaneousness of talks. Makes things hard to follow, and you have to save that somewhere, or make it happen. No it's not relevant for my needs. But I guess we already agree on that.

I think all the points you raised about the scripting language are relevant and well thought.

- There are several points of development that you raised:
AI, Game Event handling, GUI handling, and Objectives. (And the console, mostly for tests and debugging in fact.)

The campaign management, is for now and roughly speaking a set of pre-determined scenarios, thus a set of predetermined game mode (objectives, game, win/lose screen, new objectives, new game, ...) and this is something that will part of Event handling, IMHO.

As for assets management, I do think you're mixing the scripting language with the deharcoded config point. Something that we'll need of course. But, I can't tell for now whether we'll be able to use scripts as config files, for instance. That's another debate.

As the for the choice of the scripting language. I'll be honest, I would avoid switching the scripting language unless AS proves it can't be used as a lib and/or for certain features.
I've looked at the website changelog and how it used and I do think it's feasible for both.
Why? Because it is representing quite some work for nothing new, and as it's a spare time project, our motivation can vary a lot.
So, I'd say, let give AS a chance, by first upgrading the thing and make it cleaner. If we can use it as an outer lib, then I don't see why we should drop it. If not, then we'll make a new choice. And in that case, I'd recommend lua.

As a first move, I'll upgrade the dependencies files and see how it turns. Then, I'd need your help to make the dependencies an outer zip file, and have options to use system-wide deps or not, and AS as a lib or not in CMake. Would you be ok with this?

Best regards,
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby nido » 19 Mar 2014, 21:37

Bertram {l Wrote}:The campaign management, is for now and roughly speaking a set of pre-determined scenarios, thus a set of predetermined game mode (objectives, game, win/lose screen, new objectives, new game, ...) and this is something that will part of Event handling, IMHO.

May i ask whether these scenarios already include 'drop a group of heroes if keeper reaches X,Y' instances or are you talking more about selecting a map? The second sounds like something that fits within event handling, which I don't particularly consider a viable candidate for scripting. The former, however, seems to me to be a primary candidate.

As for assets management, I do think you're mixing the scripting language with the deharcoded config point. Something that we'll need of course.

I was not mixing them up, but i haven't considerated that idea you mentioned. This seems a very good idea. I have no idea though if there is more to adding model then could sanely be done in a config file. Perhaps a new thread to decide on this particular point is in order?

But, I can't tell for now whether we'll be able to use scripts as config files, for instance. That's another debate.

Practically, it is relatively easy to achieve, but I think it is a bad idea. Firstly, depending on a myriad of things i cannot exhaustively list; this could allow the user to override parts of the system itself. Any example could probably be defended against, but you essentially you end up with your config file being a program, and usually, because of the abilities of whatever language it is, it becomes significantly more complex then a config file should be.

As the for the choice of the scripting language. I'll be honest, I would avoid switching the scripting language unless AS proves it can't be used as a lib and/or for certain features.

Despite the title i gave this thread, I see no problem with that course of action for the reasons you mentioned. To that effect I would like to focus this thread the question of where and how we want to use such a scripting language rather then a language shootout.

To that effect, in my previous post i mentioned a 'top' scripting language (what you get when pressing ~) and a 'bottom' scripting language currently in our codebase. Do you think it would be viable to have a scripting language (angelscript), with extra bindings, be the environment you get when pressing ~?


As a first move, I'll upgrade the dependencies files and see how it turns. Then, I'd need your help to make the dependencies an outer zip file, and have options to use system-wide deps or not, and AS as a lib or not in CMake. Would you be ok with this?

we can separate the zipfile creation from the system dependencies job. I would be happy to do the grunt of the cmake work and post a suggestion in an appropriate thread at that time.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 20 Mar 2014, 09:23

Hi nido, :)

May i ask whether these scenarios already include 'drop a group of heroes if keeper reaches X,Y' instances or are you talking more about selecting a map? The second sounds like something that fits within event handling, which I don't particularly consider a viable candidate for scripting. The former, however, seems to me to be a primary candidate.

The campaign stuff is only conceptual atm, (no actual working code so far). That said, I was speaking about it like a set of games to win in order to complete the campaign.
And what you said here is true:
- A set of games can be part of a config campaign file.
- Events triggered within a game are more part of event handling, indeed.
--> De we agree about this?

I was not mixing them up, but i haven't considerated that idea you mentioned. This seems a very good idea. I have no idea though if there is more to adding model then could sanely be done in a config file. Perhaps a new thread to decide on this particular point is in order?

Ah ok. we don't know each other very well yet, but for the record, please don't take any of my wrong assumptions as offenses. It wasn't the case at all and it's actually great to be able to openly discuss all this. :)

I do think it's already been decided as IIRC I saw an issue about removing the creature definition from the map to put it in a new one.
We could take the chance to almost make it more configurable (if it isn't already), by adding what's lacking in there. From what I saw, it is already possible to tell the mesh file used for a creature.
I'd propose to add this in a config/ folder, btw.

The same should be done for tiles, IMHO. We'll need a tiledefinition.cfg file or something with the meshes and optional overriding materials used when using a tile type, for each biomes.
--> Feel free to correct me if you see something not fitting.

Despite the title i gave this thread, I see no problem with that course of action for the reasons you mentioned. To that effect I would like to focus this thread the question of where and how we want to use such a scripting language rather then a language shootout.
To that effect, in my previous post i mentioned a 'top' scripting language (what you get when pressing ~) and a 'bottom' scripting language currently in our codebase. Do you think it would be viable to have a scripting language (angelscript), with extra bindings, be the environment you get when pressing ~?

Ok. Well, I'm not totally sure of anything at that point. Yet, from experience, I'd say that the console top "language" should stay very primitive with a defined set of statements. (Easier for user, easier for us to prevent mistakes from them.).
Now, I can see how good it is to be able to run AS stuff from the console, and if I understood you correctly, we should add some kind of "script <AS code>" command that is permitting us to run raw AS code from the console for game debugging purpose. Did I get the idea correctly?

we can separate the zipfile creation from the system dependencies job. I would be happy to do the grunt of the cmake work and post a suggestion in an appropriate thread at that time.

Great, thanks! :)

Best regards,
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby nido » 21 Mar 2014, 01:04

Ah ok. we don't know each other very well yet, but for the record, please don't take any of my wrong assumptions as offenses.


I am very sorry for giving you this impression, this was not my intent. I was merely trying to convey that I haven't when posting I didn't think of what you proposed afterwards, even though it makes infinitely more sense.

It wasn't the case at all and it's actually great to be able to openly discuss all this.

I agree.


The campaign stuff is only conceptual atm, (no actual working code so far). That said, I was speaking about it like a set of games to win in order to complete the campaign.

I see. Thank you for clearifying.

- A set of games can be part of a config campaign file.
- Events triggered within a game are more part of event handling, indeed.
--> De we agree about this?

To be sure about it, stuff like '30 minutes in the game the keeper gets a prescripted warning', 'if any keeper claims the tile at 294x102, these six heroes drop on these predefined locations', would be handled with the event handler? If so I think we are in agreement.

Ok. Well, I'm not totally sure of anything at that point. Yet, from experience, I'd say that the console top "language" should stay very primitive with a defined set of statements. (Easier for user, easier for us to prevent mistakes from them.).


Barring language with radical paradigm differences (e.g. prolog, lisp), the choice of language comes down, more or less, to a slider between simplicity and control. At the moment we have three different levels, the top (simplest) being our console language, angelscript being the second layer, implementing part of that top layer one, and c++ as the bottom layer giving us most control, but but can be called from angelscript.

For the sake of argument, if we wish we could implement a fourth later somewhere inbetween or perhaps even on top of our simplest language (which probably needs to be extended for that though), and another one which may fall anywhere on the scale of complexity for a completely different purpose, or flatten it into one or two languages. Not saying any of this is a good idea, just that it is possible.

The 'console language' generally is indeed very simple. I have little experience with similar languages in games though my experience with bash and friends is extensive. For a console language, at the very least have its 'core' commands easy to use. Whilst a c++ console (let us not consider the implications on actually making this possible for now), may give the greatest amount of control our console could give, using even the simplest commands would be tedious due to the way it works.

I do not think having a very complex console would be a bad thing. Especially if this console can be used to control the other scripted parts of our program. Such a design would allow us to create the scripts using rapid prototyping (basically, dump script in console, see what happens, optimise based on result), and allows for 'users' to create extensive mods or changes without downloading the source code package. The console scripting (as in the scripts, not the actual art of dumping letters in the console) becomes an essential part of the codebase.

So I agree it is necessary to have a basic commands easily callable for exactly the reasons you state. I would guess that the fitness of a scripting language also used as console language would be whether casual players can build oneliners like "target.setLevel(5)".

Now, I can see how good it is to be able to run AS stuff from the console, and if I understood you correctly, we should add some kind of "script <AS code>" command that is permitting us to run raw AS code from the console for game debugging purpose. Did I get the idea correctly?


If we come to the conclusion we want to have a very simple top level scripting language, I would personally be against such a command. Reason is that this would bascially invalidate the simplicity of the console, as we still need to account for whatever angelscript is going to do. It may make sense in a debugging build for purposes you described, but I would protest having it enabled in the release builds.
Last edited by nido on 22 Mar 2014, 00:17, edited 1 time in total.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 21 Mar 2014, 02:27

To be sure about it, stuff like '30 minutes in the game the keeper gets a prescripted warning', 'if any keeper claims the tile at 294x102, these six heroes drop on these predefined locations', would be handled with the event handler? If so I think we are in agreement.

We agree.

If we come to the conclusion we want to have a very simple top level scripting language, I would personally be against such a command. Reason is that this would bascially invalidate the simplicity of the console, as we still need to account for whatever angelscript is going to do. It may make sense in a debugging build for purposes you described, but I would protest having it enabled in the release builds.

Agreed, I'd be for disabling this for "normal" users as well.

Regards, :)
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby nido » 22 Mar 2014, 00:21

My inability to format balance tags correctly may have obscured a part of my previous post (fixed now).

I would like to propose to elevate angelscript from the position of implementing the console language, to being the console language, since it is entirely viable to have a powerful scripting language which also allows simple commands.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 25 Mar 2014, 10:12

I would like to propose to elevate angelscript from the position of implementing the console language, to being the console language, since it is entirely viable to have a powerful scripting language which also allows simple commands.


It's also a fine and simpler solution as long as we can prevent running AS commands that breaks the game/system. :)
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby nido » 25 Mar 2014, 22:27

It's also a fine and simpler solution as long as we can prevent running AS commands that breaks the game/system


Ultimately I would think this would be hard to achive. Even the simplest language can be catastrophic when it allows to alter game state. A simple example would be a 'drop x creatures y' command. make x 1.000.000, and quite likely the game isn't going to like you no more. If not, do the command again, and drop y's mortal enemy. Still think the game will like you?

Another thing, since we quite explicitly leave the option open the posibility for users to run angelscripts within opendungeons, this leaves ample opportunity to make opendungeons do things it is not supposed to do, and complain about it afterwards. To this i would suggest we define a list of 'safe' functions, the effect of which we test; and tell users to keep to that set if they do not want to break things.

Nevertheless, we would still like to minimise the effect the user facing interpreter has on the game itself. To this effect I suggest we let it run in its own little process, away from the rest of opendungeons, and only allow it to fetch/send data to opendungeons through predefined functions.
These predefined functions may still allow the user to do bad things to opendungeons, depending on ones definitions, but this would save the genius who creates an endless loop in angelscript or corrupts angelscripts state. In order to even give him back his console after creating such, i suggest we allow the ability to kill that interpreter and restart it.

There would be, of course, scripts ran aside from the user's console, but I suggest we would allow the ability to (re)define every scripted part in the game, as this would allow for the actual tweaking of your script during gameplay, as well as the ability to have a level script suddenly change the rules of the game halfway (for example, two passive 'stealth'keepers just next door suddenly turn into agressive 'war'keepers for some in-game reason, or at some predefined moment "What?! Heroes broke though inpenetratable wall! Be sure to capture those dwarves alive, keeper; they may have invaluable information.")



On another tangent, if I am not mistaken, the current targets for scripting are: AI, Game Event handling, GUI handling, and Objectives, console, tests/debugging. Do you happen to know the general state of these parts of the game are? I am still in the beginning phase of understanding the codebase and knowing the current situation makes it easier to decide on a target.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 26 Mar 2014, 09:17

Hi again nido, :)

To this i would suggest we define a list of 'safe' functions, the effect of which we test; and tell users to keep to that set if they do not want to break things.

Good point. I even wonder whether we could add a parser that makes the console refuse to trigger anything else than those functions when not in debug mode.

Nevertheless, we would still like to minimise the effect the user facing interpreter has on the game itself. To this effect I suggest we let it run in its own little process, away from the rest of opendungeons, and only allow it to fetch/send data to opendungeons through predefined functions.
These predefined functions may still allow the user to do bad things to opendungeons, depending on ones definitions, but this would save the genius who creates an endless loop in angelscript or corrupts angelscripts state. In order to even give him back his console after creating such, i suggest we allow the ability to kill that interpreter and restart it.

Sounds fair. I don't know AS enough yet, but if we can create a binding instance at console opening and delete it at console closing, whatever happened here, it might be a good start.
What do you think?

(for example, two passive 'stealth'keepers just next door suddenly turn into agressive 'war'keepers for some in-game reason, or at some predefined moment "What?! Heroes broke though inpenetratable wall! Be sure to capture those dwarves alive, keeper; they may have invaluable information.")

Eh eh. Can't wait to welcome them, btw.

On another tangent, if I am not mistaken, the current targets for scripting are: AI, Game Event handling, GUI handling, and Objectives, console, tests/debugging. Do you happen to know the general state of these parts of the game are? I am still in the beginning phase of understanding the codebase and knowing the current situation makes it easier to decide on a target.

AFAIK, I've seen AS use only for the console. I might be wrong though. I think we both agree about the core logic behind the use of AS. And try and put some sequential task list here, I'd suggest we start on the AI, since it would make OD have a better gameplay right now, and since an objective system, and a game event manager are still to be created.
Just my opinon, though.

Best regards,
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby nido » 26 Mar 2014, 19:52

Bertram {l Wrote}:Good point. I even wonder whether we could add a parser that makes the console refuse to trigger anything else than those functions when not in debug mode.


Hrm... I'm not sure. Essentially, I think this would involve wrapping around the interpreter again; re-creating the top-layer language. It could get especially hairy if you still want to allow parts of angelscript. My original intention was to unceremoniously close bugreports made about using 'nonsafe' functions as 'wontfix', but still allow people to play around with it, possibly creating extensive opendungeons mods.

<edit>It would be fairly trivial to implement such access controls on the functions we define ourselves, though; if we don't care about what happens in the as terminal itself</edit>

Sounds fair. I don't know AS enough yet, but if we can create a binding instance at console opening and delete it at console closing, whatever happened here, it might be a good start.


That sounds like an even better idea then to allow control over the the interpreter separately. We could basically start that interpreter only when the console is called, and kill it unconditionally when it is closed. We should make sure that the calls to opendungeons internals are actually handled internally though; we wouldn't want to get into a situation where we should guarantee the system to still be functional after a couple of calls have only half finished (due to its caller being killed).

AFAIK, I've seen AS use only for the console. I might be wrong though. I think we both agree about the core logic behind the use of AS. And try and put some sequential task list here, I'd suggest we start on the AI, since it would make OD have a better gameplay right now, and since an objective system, and a game event manager are still to be created.


I would agree on both statements regarding angelscript. regarding the next target, the event manager might be a promising target as this could also be the jump point for the scripting to get inserted, especially if such an AI also needs access to essentially all functionality a player keeper has. An objective system may prove trivially afterwards depending on what the event manager allows. Deciding on what specifically we would like these systems to do I think would be the first step; though this can happen in parallel with efforts of actually giving a player a working angelscript console.

Here is my suggestion for the functionality of the different parts. Feel free to suggest changes or elaborations.

AI - thinking about it, there are actually two kinds of AI.
Creature AI - already exists for the most part in c; doesn't need to be scripted in my humble opinion, but I wanted to mention this ai separately.
Player AI - basically, non-player keepers and hero 'keepers'. They need at least the same access as the player keeper (spells, commands, stuffs like that), though traditionally the computer is a cheating bastard with way more access then you. I suggest we implement only the access which is required for them and let ai writers think up their own angelscripts on how when to do something, whilst not being cheating bastards (perhaps we want to make an exception for at least posession though).

event manager - "something that handles events". An event consists of two parts, a condition which must be met, and things which needs to happen when a condition is met. The 'things which needs to happen' part would be primary candidate to be a script; as we can then keep its definition as just that. The 'when a condition is met' part could also just be a script in order to allow ultimate flexibility; this would imply though that each event which could happen needs to be re-evaluated time and time again. We may benefit from defining a set of possible criteria which we can check without needing to query the event. (for example, "after 10 minutes, drop a creature", rather then to check whether 10 minutes have passed every turn, we could also calculate which turn is 'after 10 minutes' and fire the event unconditionally then. Checks for 'when creature X dies' can also be evaluated only when a death occurs, or maybe even attached to the creature to be handled automatically when it dies.


Objective system - list of conditions that wins a game; trivially if we have the beforementioned event manager, as this would be reduced to 'add a win game event'. For this reason, I think i may have misunderstood the objective system and/or event manager. However, if this is in line with what you think, the next step would be to consider how we want to run the event manager.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 27 Mar 2014, 10:29

Hi nido,

Hrm... I'm not sure. Essentially, I think this would involve wrapping around the interpreter again; re-creating the top-layer language. It could get especially hairy if you still want to allow parts of angelscript. My original intention was to unceremoniously close bugreports made about using 'nonsafe' functions as 'wontfix', but still allow people to play around with it, possibly creating extensive opendungeons mods.

If you're planning to close bug reports due to mis-use, it means the solution has got flaws, already on the design level. Or, we can simply warn users the console is a development component and shouldn't be used by regular users?

AI:
Creature AI - already exists for the most part in c; doesn't need to be scripted in my humble opinion, but I wanted to mention this ai separately.

Agree.

Player AI - basically, non-player keepers and hero 'keepers'. They need at least the same access as the player keeper (spells, commands, stuffs like that), though traditionally the computer is a cheating bastard with way more access then you. I suggest we implement only the access which is required for them and let ai writers think up their own angelscripts on how when to do something, whilst not being cheating bastards (perhaps we want to make an exception for at least posession though).

Hmm, nope. Adding bindings won't be sufficient. We need to have a proper even if basic AI for both Keepers and Heroes. It would be a good proof of concept and modders usually never start from scratch anyway. But, a step at a time, of course.
Note that a NullAI is existing and its something useful, when one wants to add "teamless" creatures that just wander around.

As for objectives, I'd say met Objectives should trigger an event. Would it be a win event, or a something-bad-happened-and-objectives-have-changed event.
There is also something important here. IMHO, a new more appealing objectives window should be made, and shown at game start (with why not a short description of the scenario and the map name).
I'd personally remove the objective small window bottom-right and move that into this window, that you could open using a button.

As for events, in Valyria Tear, there is a quite complete event manager, and basically, it's a manager that check a pile of events continously.
Creating the manager is the first step, but we should try to add event types little by little and not now. There is IMHO, enough to do on the table before that.

Best regards,
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Re: Scipting Language Choices (angelscript discussion)

Postby nido » 27 Mar 2014, 22:42

If you're planning to close bug reports due to mis-use, it means the solution has got flaws, already on the design level. Or, we can simply warn users the console is a development component and shouldn't be used by regular users?


It has flaws, yes; as does any design decision. I think the warning would be a good idea, and is also in line with my intentions. The primary use of the command line for non-modder/coder people I think would be fix accidental unwinnable situations or jammed objectives (which should be fixed in-source afterwards). I don't think these kind of people deserve a talking to about using the console when asking support afterwards.

The kind of bugs I was thinking of was where someone has upgraded the mages' basic fireball to way-beyond-game-levels genocide-the-board level, and then complain about bodies get stuck in the wall from the blast (due to the physics engine not forseeing such speeds of acceleration or whatever).


Hmm, nope. Adding bindings won't be sufficient.

Agreed, the bindings alone make for no AI on their own. The AI itself would be a script, which has access to (only?) those bindings.


As for objectives, I'd say met Objectives should trigger an event. Would it be a win event, or a something-bad-happened-and-objectives-have-changed event.

agreed

There is also something important here. IMHO, a new more appealing objectives window should be made, and shown at game start (with why not a short description of the scenario and the map name).
I'd personally remove the objective small window bottom-right and move that into this window, that you could open using a button.

I have no particular opinion about the user interface myself, but I do not think your idea is a bad one.

As for events, in Valyria Tear, there is a quite complete event manager, and basically, it's a manager that check a pile of events continously.
Creating the manager is the first step, but we should try to add event types little by little and not now.


The actual coding would be incremental, but i do not think it is bad to consider a list of likely ways we want to engage the event manager. It would be sad to implement a great and wonderful time-based event manager, only to realise next we need to completely rebuild it in order to also trigger based on your gold count.
For example, I think it seems reasonable we would be reasonable to want to trigger on things like
- absolute gametime ("you've been at this for X hours now, are you sure you havent fallen asleep on the job?")

-time since a an event (3 minutes after you kill the last hero on the level, the lord of the land comes with his posse for a final beatdown)

- keepers: you/opponents (tutorial objective: you have x gold, regular objective keeper y is dead)

- certain/any tiles claimed/walls dug (keeper ai gets replaced with an agressive one once you get too close, tutorial level win-objectives)

- one of any of a certain group (e.g. yours/opponents) creatures reached a certain state (tutorial level winobjectives like make a creature train to level 2, all opponents are decidedly dead or captured)

- number of creatures by certain keeper (since you have almost killed your opponent, the lord of the land decides to pay you a visit)

There is IMHO, enough to do on the table before that.


datastructures would be on my agenda in terms of code before scripting even. Yet, that doesn't leave out the possibility to gather ideas about this subject in advance so that when we get to that point, we already have a clear view of what we would like to ultimately achieve with these components. Whilst I am all for an agile approach in implementing features, talk is a lot cheaper then code and a lot of value can still be gained by having well thought out design ideas.
nido
 
Posts: 57
Joined: 07 Mar 2014, 00:47

Re: Scipting Language Choices (angelscript discussion)

Postby Bertram » 27 Mar 2014, 23:34

It has flaws, yes; as does any design decision. I think the warning would be a good idea, and is also in line with my intentions. The primary use of the command line for non-modder/coder people I think would be fix accidental unwinnable situations or jammed objectives (which should be fixed in-source afterwards). I don't think these kind of people deserve a talking to about using the console when asking support afterwards.

The kind of bugs I was thinking of was where someone has upgraded the mages' basic fireball to way-beyond-game-levels genocide-the-board level, and then complain about bodies get stuck in the wall from the blast (due to the physics engine not forseeing such speeds of acceleration or whatever).

You convinced me. Let's go for AS as the console language.

The actual coding would be incremental, but i do not think it is bad to consider a list of likely ways we want to engage the event manager. It would be sad to implement a great and wonderful time-based event manager, only to realise next we need to completely rebuild it in order to also trigger based on your gold count.

datastructures would be on my agenda in terms of code before scripting even. Yet, that doesn't leave out the possibility to gather ideas about this subject in advance so that when we get to that point, we already have a clear view of what we would like to ultimately achieve with these components. Whilst I am all for an agile approach in implementing features, talk is a lot cheaper then code and a lot of value can still be gained by having well thought out design ideas.

My apologizes. You're completely right about those points.
User avatar
Bertram
VT Moderator
 
Posts: 1652
Joined: 09 Nov 2012, 12:26

Who is online

Users browsing this forum: No registered users and 1 guest