Scriptable Training Missions / Tutorial System - part 1
Count
Something along these lines will get maximum participation while limiting the "fun" of learning, installing, and coding a scripting language. Don't get me wrong not having to understand all the details of Allegiance's underlying code to do some basic chores will make it easier for someone to contribute but the challenges of learning the language (for many) will limit the participation.
I get this is a very specific example but the underlying idea is what I'm suggesting. Never laid eyes on the program or hardware before and had a pretty complex test chamber complete with the IO, user interface, file storage, and control alogirthms up and running in about two weeks. It was pretty much drag and drop, double click, ???, proft. It did require I understand what I needed to do to build a test chamber from scratch, just not all of the esoteric coding, hardware/software clinkers and wierd error messager interaction stuff that is a project killer many times.
I'd guess after a googling for Rational Rose as another example you'd call it a UMLbased approach? (linkees for the others reading the thread)
MrChaos
edit: fixed broken link and added this bit. I'm not sure what level of effort I just asked you do for free btw. Just making a suggestion as asked
Something along these lines will get maximum participation while limiting the "fun" of learning, installing, and coding a scripting language. Don't get me wrong not having to understand all the details of Allegiance's underlying code to do some basic chores will make it easier for someone to contribute but the challenges of learning the language (for many) will limit the participation.
I get this is a very specific example but the underlying idea is what I'm suggesting. Never laid eyes on the program or hardware before and had a pretty complex test chamber complete with the IO, user interface, file storage, and control alogirthms up and running in about two weeks. It was pretty much drag and drop, double click, ???, proft. It did require I understand what I needed to do to build a test chamber from scratch, just not all of the esoteric coding, hardware/software clinkers and wierd error messager interaction stuff that is a project killer many times.
I'd guess after a googling for Rational Rose as another example you'd call it a UMLbased approach? (linkees for the others reading the thread)
MrChaos
edit: fixed broken link and added this bit. I'm not sure what level of effort I just asked you do for free btw. Just making a suggestion as asked
Last edited by MrChaos on Sun Jul 17, 2011 4:13 pm, edited 1 time in total.
Ssssh
If you want non-programmers to be able to write your scripts. Why ask which existing programming language the scripts should be written in? Non-programmers won't know the difference between them or have any experience with them (by definition of being non-programmers). So perhaps you are asking programmers which would be best for non-programmers?
When you ask which existing language to use, are you asking "which is easiest to learn for non-programmers?" or "which would be most suitable to write missions in?".
I think you're doing it wrong.
I think the questions you should be asking are more like:
"What kind of things/missions should be possible to script"
"How can I make it easy to scrip them, in a way that's intuitive and easy to learn for non-programmers" - note you don't need to dumb it down (think of the type of people who learnt core making in ICE - allegiance cores weren't designed to be readily understood by the average player (they were designed to be used efficiently by computers), but people do learn them when they put the effort in).
I think you should be thinking of making your own scripting language give it a load of useful functions (compare how you do things like move the mouse pointer to the location a matching image on screen in a web page in autohotkey vs how you would do it in C++ C# python etc). I'd also suggest you make it event driven, maybe you should play with starcraft's mission/map editor (the original starcraft, I haven't tried the new starcraft's mission editor) - that's one of the most successful mission creation tools ever I think.
A simple text based language could work
See if you can figure out what's going on:
See if what you think the above does matches what I was thinking (i.e. is it obvious what it does and how):
Script is made up of blocks of the form:
EVENT: some event
[CONDITION]: Optional condition - only execute the DO bit if this condition evaluates to true, if condition is not present always execute DO on the event firing
DO:
script actions here
script is determined to stop when either the next event block is reached or the EOF is reached.
INIT is an event that is called automatically once at the start of the mission, can be used to initialise variables, trigger the mission briefing etc.
You can have multiple event handlers for the same event (in above e.g. there are two handlers for the INIT event), both execute concurrently (neither "consumes" the event in a race condition type of manner).
Script does the following
Initialises a variable objective to 1 (mentioning a variable creates it) and displays a message.
When a kill event is triggered which has the local player killing a ship that is capable of mining at any location another variable is created and set and a move order is issued to the player
When the player moves within 1000m of 150,30,0 (some x,y,z position in the sector the player is in - as the sector is unspecified) a condition is tested - if myFlag1 has been set. If the miner hasn't been killed then that flag doesn't exist so condition evaluates false and nothing happens, if the player has killed the miner (or otherwise done something to set myFlag1) then an aleph is unlocked (why shouldn't we be able to enable/disable passage through alephs in scripts?), the objective variable is incremented, a message is displayed then some other user defined event is triggered.
Well, there's a bit of a simple mission written in a made up scripting language that resembles english in ~20 short lines. Do you think something like the above would be easier for non-programmers to use than say python or javascript?
You could even make a GUI script editor with drop down boxes with the available options etc in.
MrC, I'd suggest avoiding a visual programming language is only because they can get very messy (even if they have auto tidy-up tools, here's some labview I did as a side project in my PhD), also not everyone has 3 24" monitors. I'd also suggest against them because they're good for sequential operations on data (though array manipulation in labview can get pretty wtf when looking at code you drew a while ago) but mission writing is more event driven.
When you ask which existing language to use, are you asking "which is easiest to learn for non-programmers?" or "which would be most suitable to write missions in?".
I think you're doing it wrong.
I think the questions you should be asking are more like:
"What kind of things/missions should be possible to script"
"How can I make it easy to scrip them, in a way that's intuitive and easy to learn for non-programmers" - note you don't need to dumb it down (think of the type of people who learnt core making in ICE - allegiance cores weren't designed to be readily understood by the average player (they were designed to be used efficiently by computers), but people do learn them when they put the effort in).
I think you should be thinking of making your own scripting language give it a load of useful functions (compare how you do things like move the mouse pointer to the location a matching image on screen in a web page in autohotkey vs how you would do it in C++ C# python etc). I'd also suggest you make it event driven, maybe you should play with starcraft's mission/map editor (the original starcraft, I haven't tried the new starcraft's mission editor) - that's one of the most successful mission creation tools ever I think.
A simple text based language could work
See if you can figure out what's going on:
Code: Select all
EVENT: INIT
DO:
objective=1
EVENT: INIT
DO:
DISPLAY MESSAGE "Go kill that miner and wait for further instructions"
EVENT: PLAYER kills 1 MINER ANYWHERE
DO:
SET myFlag1
ISSUE ORDER PLAYER move 150,30,0
EVENT: PLAYER within 1000m of 150,30,0 //event is triggered whenever player is close to some x,y,z
CONDITION: isSet(myFlag1) //and player has previously completed the objective
DO:
UNLOCK Aleph2
objective++
DISPLAY MESSAGE "Nice work move onto your next objective"
TRIGGER EVENT myCustomEventScript is made up of blocks of the form:
EVENT: some event
[CONDITION]: Optional condition - only execute the DO bit if this condition evaluates to true, if condition is not present always execute DO on the event firing
DO:
script actions here
script is determined to stop when either the next event block is reached or the EOF is reached.
INIT is an event that is called automatically once at the start of the mission, can be used to initialise variables, trigger the mission briefing etc.
You can have multiple event handlers for the same event (in above e.g. there are two handlers for the INIT event), both execute concurrently (neither "consumes" the event in a race condition type of manner).
Script does the following
Initialises a variable objective to 1 (mentioning a variable creates it) and displays a message.
When a kill event is triggered which has the local player killing a ship that is capable of mining at any location another variable is created and set and a move order is issued to the player
When the player moves within 1000m of 150,30,0 (some x,y,z position in the sector the player is in - as the sector is unspecified) a condition is tested - if myFlag1 has been set. If the miner hasn't been killed then that flag doesn't exist so condition evaluates false and nothing happens, if the player has killed the miner (or otherwise done something to set myFlag1) then an aleph is unlocked (why shouldn't we be able to enable/disable passage through alephs in scripts?), the objective variable is incremented, a message is displayed then some other user defined event is triggered.
Well, there's a bit of a simple mission written in a made up scripting language that resembles english in ~20 short lines. Do you think something like the above would be easier for non-programmers to use than say python or javascript?
You could even make a GUI script editor with drop down boxes with the available options etc in.
MrC, I'd suggest avoiding a visual programming language is only because they can get very messy (even if they have auto tidy-up tools, here's some labview I did as a side project in my PhD), also not everyone has 3 24" monitors. I'd also suggest against them because they're good for sequential operations on data (though array manipulation in labview can get pretty wtf when looking at code you drew a while ago) but mission writing is more event driven.
Last edited by madpeople on Sun Jul 17, 2011 4:56 pm, edited 1 time in total.
"non-programmers" is a very vague notion.
There is a huge step between programming in C++ within Allegiance code and writing scripts. That's the whole point here.
A lot of so called 'non-programmers' with enough brain can do nice things with a scripting system whatever the language.
These same persons will refuse to invest time in C++ because of the complexity and burden.
I'm not talking about C++ as a language alone but about a complex C++ project like Allegiance with all the libraries, SDKs, tools and knowledge required.
As far as I'm concern the scripting language itself is not a key element. I asked about it simply to get a general feeling. What matters is the global environment.
I don't see the point designing a brand new language because I want to leverage existing stuff.
Adding scripting to an application can be complex. Using existing parsers and error handling modules of an existing language is the way to go.
Using existing language(s) allows to reuse code too. Either by direct import (with 'modules') or by copy/pasting. Python and JS have a big advantage here, there are tons of existing modules out there for all sort of things.
I might even go for multi-language scripting, leaving the choice to the users. Something like Active Scripting might be the way to go.
Actually it has already been done in Allegiance. The Pigs system uses it. I might reuse this. Take a look at the original Pigletsfor instance. You'll see the language is a parameter of the 'pigs'.
The 'scout2' piglet is a nice example of why using a widely used scripting language is interesting. by using JavaScript, they were able to quickly adapt/reuse Dijkstra's shortest path algorithm in a module and then use it in the piglet (see include/dijkstra.js). Try doing this with your own language, you'll have to reinvent the wheel.
A GUI system is way too soon to even think of it. It could be added later by someone else as it doesn't need Allegiance code to work. That's the advantage of this approach too.
There is a huge step between programming in C++ within Allegiance code and writing scripts. That's the whole point here.
A lot of so called 'non-programmers' with enough brain can do nice things with a scripting system whatever the language.
These same persons will refuse to invest time in C++ because of the complexity and burden.
I'm not talking about C++ as a language alone but about a complex C++ project like Allegiance with all the libraries, SDKs, tools and knowledge required.
As far as I'm concern the scripting language itself is not a key element. I asked about it simply to get a general feeling. What matters is the global environment.
I don't see the point designing a brand new language because I want to leverage existing stuff.
Adding scripting to an application can be complex. Using existing parsers and error handling modules of an existing language is the way to go.
Using existing language(s) allows to reuse code too. Either by direct import (with 'modules') or by copy/pasting. Python and JS have a big advantage here, there are tons of existing modules out there for all sort of things.
I might even go for multi-language scripting, leaving the choice to the users. Something like Active Scripting might be the way to go.
Actually it has already been done in Allegiance. The Pigs system uses it. I might reuse this. Take a look at the original Pigletsfor instance. You'll see the language is a parameter of the 'pigs'.
The 'scout2' piglet is a nice example of why using a widely used scripting language is interesting. by using JavaScript, they were able to quickly adapt/reuse Dijkstra's shortest path algorithm in a module and then use it in the piglet (see include/dijkstra.js). Try doing this with your own language, you'll have to reinvent the wheel.
A GUI system is way too soon to even think of it. It could be added later by someone else as it doesn't need Allegiance code to work. That's the advantage of this approach too.
Last edited by KGJV on Sun Jul 17, 2011 6:25 pm, edited 1 time in total.
fine
Took a scripting language specific for some propertary program based on Fortran. Built a VB interface to make it easier to use and it worked... with me dinking with things.. while being a big ol free time sink and a negative time saver when factored in.
*mutters under his breath*
Got the point gents
I change my answer to: what Madpeeps said
Count I know none of these languages well and hate Python with a passion the clunky Linuxesque pos with the endless "flavors"
. Anyhoo I do agree not having to climb the mountain of Allegiance code would make it more attractive to others to do stuff. Then to C++ expertise isn't something we seem to have in abundence.
I will take a peak at pigs and piglets and such over the next few days and give you feedback... if you wish and I can figure out how get to it... hmmmm
MrChaos
Took a scripting language specific for some propertary program based on Fortran. Built a VB interface to make it easier to use and it worked... with me dinking with things.. while being a big ol free time sink and a negative time saver when factored in.
*mutters under his breath*
Got the point gents
I change my answer to: what Madpeeps said
Count I know none of these languages well and hate Python with a passion the clunky Linuxesque pos with the endless "flavors"
. Anyhoo I do agree not having to climb the mountain of Allegiance code would make it more attractive to others to do stuff. Then to C++ expertise isn't something we seem to have in abundence.I will take a peak at pigs and piglets and such over the next few days and give you feedback... if you wish and I can figure out how get to it... hmmmm
MrChaos
Ssssh
your Chaosness,MrChaos wrote:QUOTE (MrChaos @ Jul 17 2011, 09:04 PM) Count I know none of these languages well and hate Python with a passion the clunky Linuxesque pos with the endless "flavors"
I will take a peak at pigs and piglets and such over the next few days and give you feedback... if you wish and I can figure out how get to it... hmmmm
MrChaos
I confess I do hate Python too, for reasons beyond the scope of this topic.
As for pigs and piglets, they're not very good samples of what training mission scripts would look like. They're more example of what the AI script code would look like.
Training mission scripts would be more simple and linear (although event based too).
So if you can figure out the pigs, then mission scripts should be a piece of cake
It is barely more difficult than editing an MDL file. The only real difference is needing to download the source and compile it. Its not like your are writing complex code from scratch to make the training missions. They built in a relatively simple system for writing missions.Bunnywabbit wrote:QUOTE (Bunnywabbit @ Jul 17 2011, 08:12 AM) If the level of complexity of editing a training mission were on a par with editing an MDL file, there's a good chance I'd be all over that. I'm sure most of us Arty types would be.
Honestly if I were going to make them easier to do I would practically just copy the system they used but separate it from the code. That is I would build into the code the ability to read mission instructions from an MDL file. The MDL file would basically reuse the system that Microsoft built in except that instead of needing to be compiled it would build it when a mission is launched. There is no need to reinvent the system. The only way to make it significantly easier for non programmers is to build a UI that took you step by step through putting a mission together and translated it into code.
Its not that the AI is just not good. Drones are barely usable for combat period. The AI is broken. Its like someone thought hey lets build in some drone combat AI and worked on it for five minutes before giving up.Bunnywabbit wrote:QUOTE (Bunnywabbit @ Jul 17 2011, 08:12 AM) On the other hand, i don't remember giving a @#(! about the drone AI. As a player, you know you are in a sandbox version of the game; you know what you're shooting at are just dumb robots. It would be cool if the AI were better, but we could really make some nice stuff if the tools were better.
Last edited by aem on Sun Jul 17, 2011 11:51 pm, edited 1 time in total.
AEM and Count
so it would be kinda like scenario editors from different games Ive fiddled with in the past (I'm thinking specifically of Harpoon but that may be to vague of a game reference even here). However we'd be stuck with errrm the stupid AI until one you gents dug around in their cranium with the surgical tools of C++ instead of the whip and chair of scripting?
If that is basically it then clickee clickee
MrChaos
so it would be kinda like scenario editors from different games Ive fiddled with in the past (I'm thinking specifically of Harpoon but that may be to vague of a game reference even here). However we'd be stuck with errrm the stupid AI until one you gents dug around in their cranium with the surgical tools of C++ instead of the whip and chair of scripting?
If that is basically it then clickee clickee
MrChaos
Last edited by MrChaos on Mon Jul 18, 2011 12:56 am, edited 1 time in total.
Ssssh
-
Bunnywabbit
- Posts: 965
- Joined: Sun May 15, 2005 7:00 am
- Location: Amsterdam, the Netherlands
That would work for me too.AEM wrote:QUOTE (AEM @ Jul 18 2011, 01:48 AM) That is I would build into the code the ability to read mission instructions from an MDL file. The MDL file would basically reuse the system that Microsoft built in except that instead of needing to be compiled it would build it when a mission is launched.
current version r158 new beta as of jan 23 2012