Topic: Configuration and Scripting

[[UFP]Exeter]

A key area to discuss is the scripting language, what to script and how.

First, for game configuration data I am leaning toward XML. 

Storage of other game data, could be in XML, an open database or even a scripting language.

The missions will also be done in a scripting language.  The ones discusses so far are LUA, Angelscript and Python.  Anyone with actual experience, please chime in.  Other than needing one we have not decided which.  Personally I prefer Angelscript.  The reason is because it is very easy to implement te parser in code (already done) and the syntax is more like C++, which to me is much easier to write and understand compared to LUA which is C based. 

[d4v1ks]

That's a very interesting topic.
I've looked at angelscript and it seems very straightforward.
The question here, for me, relies on what people want to script if they had a chance to do it right now.

For example:
In SFB, there is scenarios. A mission have a historic background; number of players that participates; a setup about the objects that exist in the area (planets, asteroids, stars, black holes, etc); a setup about the players relations (teams, etc); and theres an objective to achieve.
Some of the things above can be easily achieved, like what is the historic background, the number of player that are going to participate, how the teams are composed, what kind of objects exist in the area of space and where they are. The big question for me relies on the kind of objectives we could have and how to track them.

So, before we enter in the script topic, we could ask to the people here, what they want to be hable to do in a mission, or campaign, like, for example, the ones that exist in SFC.
Then, people could start to talk about a script implemention of those ideias.
Its a start.
So, comunity what you want to be hable to do in a mission (beside, X players of team A destroy Y players of team B  ) ?

[[UFP]Exeter]

You point is well taken, and it really requires the game to be configured to read that from the script.  Also, the script itself can be a program that runs a mission.

As for what can be configured, everything you mentioned and more.

But to design the script reader we need to decide what to include in the mission script and how it will be handled.

Another reason for AngelScript, I an already to this.

[Captain Adam]

.

[Starfox1701]

This might help us evaluate Lua better. I understand the attraction of Angelscript but am concerned that  the syntax might be more difficult to learn for people without a working understanding C++.

https://dl.dropboxusercontent.com/u/3697428/Programming%20in%20Lua%2C%20Second%20Edition-2010kaiser.pdf

[d4v1ks]

Exeter]
But to design the script reader we need to decide what to include in the mission script and how it will be handled.

For example:
We could create a structure with the basic data of the mission (looking to the example i gave) and call a function in the script, passing that object by reference, to get the data.

class PlayerData(
   Race
   WhoIsOnShip (computer/human)
   Kind of ship that can use (of the case of a computer generated player)
   etc
)

class TeamData(
   NumberOfPLayers
   PlayerData Player[]
   etc
)

class MissionData(
   HistoricBackground

   Number of Teams
   TeamData Team[]

   Number Of objects in space
   SpaceObject Objects[]

   MissionStatus

   etc
)

MissionData mission;

script->SetupMission(*mission)

Than, we could use an event based system to track down the mission objectives

int ScanMade(*obj){
    script-> ScanMade(*obj)
}

int ObjectDestroyed(* obj){
   script-> ObjectDestroyed(*obj)
}

etc

[[UFP]Exeter]

Starfox: LUA is C based, Angelscript is C++ based, which makes angelscript much easier than LUA.  Unless you already know LUA.

d4v1ks:  I agree.  My concern is any scripting will be slow, so we need a robust Mission API, to minimize any runtime scripts.

Captain Adam:  All you mentioned is possible using scripts to control missions.

[d4v1ks]

My concern is any scripting will be slow, so we need a robust Mission API, to minimize any runtime scripts.

You could code almost everything in your game, and use the script just to keep track of things.
We could build, for example, event objects and put them in a tree inside of the mission object.
While in the game loop we test if the conditions were met and only call script functions when
the current mission's objective is achieved.

//------------------------------------------------------------------------------------------------------------------
// ingame
//------------------------------------------------------------------------------------------------------------------

SCAN_MADE = 1
BEAM_UP = 2
ENEMY_DESTROYED = 4
LEAVE_HEX = 8

class EventData{
   Conditions
   Goal
   ptrFunction

  EventData Child;
  EventData Brother;
}

class MissionData(
     All things in the last post
                 +
     EventData currentNode;
     EventData eventTree;
)

MissionData currentMission;

GameLoop()
{
   // to be hable to use it inside of the script...
   script->RegisterGlobalFunction(PrintStuffInConsole( *text))
   script->RegisterGlobalFunction(AddEnemyToCurrentGame())

   script->SetupMission(*currentmission)

   currentMission.currentNode = currentmission.eventTree

   do
       //play the game...

   until TestEventTreeConditions(*currentMission.currentNode) = MISSION_DONE   
}

PrintStuffInConsole( *text){
    game->console->print (*text)
}

AddEnemyToCurrentGame(){
    enemies[] = ListEnemies(player)
    enemy = enimies[random]

    game->create(enemy)
    game->add(enemy)
}

TestEventTreeConditions (*node)
{
   do
       if (node.Conditions AND node.ConditionsRequired) == node.ConditionsRequired
       (
           r = script->CallFunctionByPtr(node.functionptr)

           if node.child != NULL (
              node = node.child
              return NEXT_MISSION
           ) else (
              return MISSION_DONE

             game->points += r
           )

       ) else (
           node = node.brother
       )
    until node = NULL

}

ScanMade(){
   currentMission.currentNode.conditions OR= SCAN_MADE
{

BeamUp(){
   currentMission.currentNode.conditions OR= BEAM_UP
{

EnemyDestroyed(){
   currentMission.currentNode.conditions OR= ENEMY_DESTROYED
}

OtherStuff(){
   currentMission.currentNode.conditions OR= OTHER_STUFF
}


//------------------------------------------------------------------------------------------------------------------
// on the script
//------------------------------------------------------------------------------------------------------------------


SetupMission(*mission)
{
   setup all the things in the last post...

  // 1º scan planet
  CreateEvent(mission.eventTree,
              SCAN _MADE,
              *ScanMade
  )


  // 2º beam up resources
  CreateEvent(mission.eventTree.Child,
              BEAM_UP,
              *ResourcesOnboard
  )


  // 3.1º evade current hex map AND Destroy enemy incomings
  CreateEvent(mission.eventTree.Child.Child,
              LEAVE_HEX & ENEMY_DESTROYED,
              *MissionComplete
  )

  // 3.2º evade current hex map
  CreateEvent(mission.eventTree.Child.Child.Brother,
              LEAVE_HEX,
              *MissionEvaded
  )
}

CreateEvent(*node, Goal, *ptrFunction){
    node = new EventData

    node.Goal = Goal
    node.prtFunction = *ptrFunction
}

ScanMade()
{
    PrintStuffInConsole("The planet seems to have the resources you want")
}

ResourcesOnboard()
{
    PrintStuffInConsole("Comander the resources are onboard already")
    AddEnemyToCurrentGame()
}

MissionComplete()
{
    return 5 points;
}

MissionEvaded()
{
    return 1 points;
}

[d4v1ks]

from the scripter perspective we have something like:


Mission:
     Background:
          Your mission is to scan the planet and beam up the medical resources that your crew need.
          If you enconter any enemy resistance you have the option to destroy them.
          Leave the hex when you are done.

     Setup:
          1 human player
          1 enemy AI
          1 star
          1 Planet


                          Scan the planet
                                    |
                                    |
        Use the transporters to beam up the resources
  (add a enemy of the player if the operation is suceeded)
                                    |
                                    |
                                    |----------------------------------------------------+
                                    |                                                                 |
                                    |                                                                 |
                      Leave the space hex                           Destroy all the enemy incomings and leave the hex
                             (1 point)                                                       (5 points)

[d4v1ks]

After this we could use our imagination and go further.
Why not create a tree of missions and call that a campaign?

[[UFP]Exeter]

We will also me using a Fixed State Manager for AI, so the states, what they do and what causes changes to other states could be coded into the AI.  This would be mission specific and the AI will have a FSM already created in the game.  Plus I am considering saving history to be used for the FSM to learn.  For example if could learn a particular strategy does not work, so it does not use it.

[d4v1ks]

Learning:

That kind of aprouch has a downside.
Cause, we can give to AI a false image of sucess.
Just imagine people teaching the AI bad strategies, by loosing on purposely. Just to mess it up

[[UFP]Exeter]

Very true.  but there are ways to compensate.

[d4v1ks]

(...) but am concerned that  the syntax might be more difficult to learn for people without a working understanding C++.

That's not always true...
The programmer can encapsulate much of the code that people will use.
So in the end you will script things like

AddThis();
AddThat();

Mission1 = CreateMission(this, that, bla, bla);
Mission2 = CreateMission(this, that, bla, bla);

Mission1.Next = Mission2;

etc...

So in the end it could be easy to code and add things on those scripts.

[[UFP]Exeter]

Regretfully, something I was hoping to avoid, for then the scripts are running the game.  Performance bottleneck.  And puts game control in the hands of a script.    It may be because I do not know how to script, but I see for a mission load the game loads the starting script for a mission and start the AI.  The AI works with states, if we wish to give the script control over the AI, how do we do this?

[d4v1ks]

What kind of control you were thinking? Cause, beside setting the AI dificulty in the script don't see why you need to control the AI in a script

[[UFP]Exeter]

That is the point.  How far do we go with the script?

I think we need a verbose AI API, and allow many many parameters for creating missions.  Including defining what AI state is called in certain situations.  But the code do do this is built in the game, rather than run code in script.  And given this, in theory we could use a text file of XML.  But using a scripting language allows us to expand the game.

[d4v1ks]

So, you are thinking in giving to AI some mission objectives or priorities? And script that?
Illustrating, in mission A, the players will need to do this and AI will try to do that?

[d4v1ks]

Lol, just imagined...
How would it be like, if we could script a AI to do the missions or campaigns that are available to the players?
That would be the ultimate AI test.

[d4v1ks]

The only way i see to do that is just by setting the AI objectives in a script once, and then running everything in the game without acessing scripts again.
Like in the Robocop movie. He had PRIME DIRECTIVES that ruled his behavior.

[[UFP]Exeter]

Hmmm   could be interesting.

The AI would control ships in combat.  For example we program tons of strategies.  Tactical combat maneuvers.  Then it uses them and it learns based on results which strategy is best against a player. 

Missiopn objectives, starting ships, reinforcements and other details in the script.  AI difficulty will be selectable when the mission is. 

AI will be coded using a midified FSM, so not really possible in a script.

[d4v1ks]

AI will be coded using a midified FSM, so not really possible in a script.

So, you just plan to hardcode the AI for a single objective: try to destroy a player using the best strategies that he can?

but I see for a mission load the game loads the starting script for a mission and start the AI

And, you just want to acess the script once at the start, load the AI, and never touch it again for the current mission?

[[UFP]Exeter]

So, you just plan to hardcode the AI for a single objective: try to destroy a player using the best strategies that he can?

The AI would get its mission directives from the mission script.  But how it tries to achieve them will be codded internal

And, you just want to acess the script once at the start, load the AI, and never touch it again for the current mission?

Mission scripts will be read at the start of the mission only.  Give we are running multithread and using the GPU, reading during combat poses additional problems besides performance.  If we did this we may as well write the game in C# and use C# as the scripts.

[d4v1ks]

Well that just kills the need for a scripting language.
Cause even a text file would be enough to config it, using a custom parser.
But, as it seems Angelscript is capablr of running in a multithread environent. Have you looked at it?

[Starfox1701]

Mission design is not really my thing in that I have no experience so I can't really comment on whether this is a good idea or not I just don't know.  On the scripting language question I think we need to try both Lua and Angelscript out and see ultimately which method produces the most readable file and which gives us the most flexible files.   

[[UFP]Exeter]

Well that just kills the need for a scripting language.

Not really as we are discussing and for future expansion.  Allot depends on what we can find out.  I know SFC missions were compiled and had an API for missions.  Possibly do that. bit instead or AI being imbedded in missions have more of the core behaviour in the game.  One issues was how the AI performed in combat. 

On the scripting language question I think we need to try both Lua and Angelscript out and see ultimately which method produces the most readable file and which gives us the most flexible files.   

One way is to look at sample scripts from each.  The documentation indicates LUA is similar to C and Angelscript is C++.  In fact to use LUA I need a C++ wrapper for LUA as the game is in C++.

[d4v1ks]

I understand your perfomance concerns.
But letting AI out, and getting back to the mission scripts, i think that accessing the mission's script once at start will limit the kind of missions you will be hable to do.
in the pseudo-code i wrote, the mission's script is executed at start, an then only when the mission's status change. It could pass some minutes between each calls. Just review the ideia.
Don't understand how executing functions in a mission's script, 3 times during the mission, could hurt the game perfomance.
If you only want to acess it once at start anyway, how you will transverse the mission lines and produce custom reactions? You would need to develop a kind of virtual machine also to handle the diferent mission requirements and reactions, if i make my self clear.

[d4v1ks]

After a small research i can comfirm that AngelScript is thread-safe. You can run it on a multithread enviroment, being hable of running multiples scripts at once and even on diferent thread spaces.

[d4v1ks]

Just thought in a way to acess the mission script just one time at the start, and do the same things as i wanted to do with the first aprouch.

void GameConsolePrint( *text ) {
    // print the text into the game's ui computer console
}

void AddEnemyToGame( *race ) {
    // add a enemy of that race to the game
}

etc...

int *functionPtr[];

void GameStart() {
    functionPtr[0] = &GameConsolePrint
    functionPtr[1] = &AddEnemyToGame

    etc...

    script->Setup(*MissionData)

    do
           // track game events...
    loop until TestEventTreeConditions(*currentMission.currentNode) = MISSION_DONE   
}

TestEventTreeConditions (*node)
{
   do
       if (node.Conditions && node.ConditionsRequired) == node.ConditionsRequired (
           r = script->CallFunctionByPtr(node.functionptr)

           select case Index[node.arg_type && node.total_args]
           case x   
              r = (*functionPtr[node.function])(node.Arg[1]);
           case y
              r = (*functionPtr[node.function])(node.Arg[1], node.Arg[2]);
           etc...

           if node.child != NULL (
              //step into next mission

              node = node.child
              return NEXT_MISSION
           ) else (
              //the mission has ended

              return MISSION_DONE
           )

       ) else (
           //if the current mission node was not fulfied try the other mission at the same tree level...

           node = node.brother
       )
    until node == NULL
}

CONSOLE_PRINT = 1
ADD_ENEMY = 2
etc...

void Setup(CObject *MissionData) {
    //setup all the things in the last posts...
    //but we use a new event creator now...
 
    // 1º scan planet
             
    CreateEvent(mission.eventTree,
        SCAN _MADE,
        CONSOLE_PRINT,
        1  //number of args,
        "The planet seems to have the resources you want"

    //Other mission events...
    )
}

CreateEvent(*node, Goal, funcIndex, funcTotalArgs, Arglist]{
    node = new EventData

    node.Goal = Goal
    node.Function = funcIndex
    node.total_args = 1
    node.arg[] = arglist
}

[[UFP]Exeter]

That could work.

The idea is to read the scripts and have all the necessary events loaded into memory for the mission.  My concern is if we need to load a script or information from a file, performance is dead.  But we also want to minimize the memory requirements .

If we can create some generic events in the game code for missions and then pass then parameters from the script that is ideal.  Some events will be unique to a mission and being able to load them for use  is fine.

So, d4v1ks, you interested in heading up the script area?  and Missions?  That does not mean doing all the work.  but based on how the scripts will be designed we also design the mission API.  and that can drive the AI API. 

[Starfox1701]

2 questions, what language are those purposed scripts in and how will all this effect unit and equipment scripts?

[d4v1ks]

You are doing all by yourself till now, right?
I really like to talk about a project like this. I'm a star trek fan. I enjoyed the board game, the SFC also.
One thing is giving ideias. I like the challange of solving things. But atm i am doing my own projects. I'm writing 2 games for Windows phone\android. The ideia is to get some extra money.
Going deeper into coding means hard work. I would have extra responsabilities. Its too early to talk about that proposal. Put that ships flying like you talked with good graphics and them i will help you. Mission or AI can wait a little more.
Still waiting for the the detaiçs of your game design 

[d4v1ks]

2 questions, what language are those purposed scripts in and how will all this effect unit and equipment scripts?

The language i used its not a standart language. I wrote about an ideia. Not true code.
I was giving ideias about an script implementation inside the context of the script language that Exeter wanted.
About those unit and equipments, a person can implement all your wishes. That the beauty of coding.

[[UFP]Exeter]

2 questions, what language are those purposed scripts in and how will all this effect unit and equipment scripts?

The scripting language is not decided.  I would like d4v1ks's opinion on that as he seems to have more experience in that realm.
Not sure how it will effet unit and equipment scripts.  The base game will have them embedded and not changeable.  But they can be overwritten or others added.  This was mods can change unit and equipment.

You are doing all by yourself till now, right?
I really like to talk about a project like this. I'm a star trek fan. I enjoyed the board game, the SFC also.
One thing is giving ideias. I like the challange of solving things. But atm i am doing my own projects. I'm writing 2 games for Windows phone\android. The ideia is to get some extra money.
Going deeper into coding means hard work. I would have extra responsabilities. Its too early to talk about that proposal. Put that ships flying like you talked with good graphics and them i will help you. Mission or AI can wait a little more.
Still waiting for the the detaiçs of your game design 

Just making sure you are willing when the time arrives.  Also means you input on how things are designed and which script language to use. 
Not looking for any coding at this point, but flushing out the design.  I know that takes time.  The ideas I have gathered will be used to modify and enhance the design I have, and it took many months of research.

I am still planning on finished the design this weekend.

[[UFP]Exeter]

I propose we settle on Angelscript as it is multithread, easy to implement, and it is a known script language.  Being C++ bases it is a little easier to understand that LUA (C based).

If we have to change it later we will, not a major issue.  The we can focus discussion on standards, what we want to do, etc. 

[Lieutenant_Q]

I too, know nothing about scripting, I can write pseudo-code for missions, but I couldn't convert it to actual code.  One thing that sticks out though, is the adaptive AI.  There's a number of things that the AI does that makes me facepalm.  But rather than having the AI learn on the fly, it should be set up that the game sends "performance" reports to a central location, where people can say... well, this is a weakness of it, we need to address this.  This was just the player making a monumental mistake (either intentionally or not) the AI SHOULD NOT be trying to take advantage of that.  (One thing that just popped into my head was the Player purposefully dropping their forward shield when they finished charging their overloads to coax the AI to make a move to attack the downed shield, which, ordinarily would be a good tactic, but with the player ready to unleash a full alpha strike, would be a very BAD tactic.  And then a possible fix to said tactic, the ability to remember things like weapons statuses and shield strengths going back a couple of minutes, so that if a shield went from 30 to 0... the AI should smell a trap, unless said shield just got hit by a 50 point Plasma Torpedo.) 

The AI being able to guess as to when a weapon was ready to fire again would be a big help, if the Player just launched a volley of Photon Torpedoes, the AI should be able to recognize that it has two turns minimum before those weapons can be fired again, and move to take advantage of that.  I think adding Memory ability to the AI would be a massive upgrade, so that it not only is trying to determine the best tactic for the moment, but so that it remembers what happened just a couple of minutes ago, and uses that to build on that tactic.

I think the easiest way to record it (again, I have limited programming experience) is to track every weapon that has a arming time of LONGER than 1 turn.  Phasers, Disruptors, and most Drone Racks are not tracked.  As soon as the AI detects the Heavy Weapon (either by sensors, or the weapon firing) it puts a timer on it, that timer is equal to the amount of time it would take to charge at that game speed. (so a real time game would set a Photon Torpedo timer at 60 seconds)  While the timer for the weapon is greater than 0 the AI would act more aggressively trying to take advantage of the fact that the weapon is still loading.  Once the timer reached, say 15, the AI would go into a defensive posture, ready to counter the Plasma Torpedo that could be launched as soon as 15 seconds.  The number can be updated through Tac Intel, so if it gets close enough to tell that the Player (or other AI) isn't charging their Heavies as fast as possible, it can reset the timer accordingly.  A threshold would have to be set, based on the AI's ship size (and possibly damage state), as to how much heavy incoming fire it would be willing to take.  So that if someone decided that they would just be charging one Heavy, or holding a single Heavy in reserve just to keep the AI on a defensive footing, the AI could determine, that it was willing to take a single Photon, even an Overloaded Photon, to close on the player while he's reloading the other three.  Or that that F-torp that's loaded and ready just isn't a big enough deterrent to keep my fully shielded cruiser from closing and hosing, but if I don't get in in the next 45 seconds, the Player will have that big nasty R-Torp ready for me...

[[UFP]Exeter]

Very good suggestions and much of that is being thought about.  The AI will used a modified Fixed State machine (FSM).  The idea is there will be strategic strategic states that govern the overall strategy of the AI.  And during the tactical portion there will be other rules that will change, but still within the strategic rule.  Like a hierarchy. 

The exact details of how this works cannot be discussed in public forums.

[Captain Adam]

.

[[UFP]Exeter]

The specifics of the AI cannot be in public forums.

To protect the code we are using the Trade Secret laws of the US.  So if for some reason somebofy thinks we my have used SFB stuff and want to review our code, we say no, as they are protected as trade secret.  The difficulty lies that we control access to the knowledge, ergo a non disclosure.

So in general we can discuss but when the discussion gets to close to actual implimentation and how, then I have to pull back.

AI is one of those areas as my thesis was on AI in computer gaming and I did some research there, my knowledge can give us an advantage.

[Captain Adam]

.

[d4v1ks]

(...)
The AI being able to guess as to when a weapon was ready to fire again would be a big help
(...)
As soon as the AI detects the Heavy Weapon (either by sensors, ...)
(...)

You gave a simple solution to the problem you raised.
In SFC, for example, we can scan the enemy ships system and weapons. And we see that happening all over the star trek series.

So we could have a sensor array in our ships that gives us reports, in a time interval, about the weapon's status of the ship we are scanning at the moment.
I imagine it like having a range.
For example, at farther distances, we can get the weapon reading signals. That would give us information about the type of weapons the ship has.
At closest range, our scanners could give us aditional information, like the energy readings of the weapons. Using our ship's futuristic computer systems we could interpret that information.
That would give us room for many implementations.
In other games they actually are connecting the systems in the ships to make them more realistic (cause-effect). They are doing that at excalibur or star citizen.
So, for example, if our scanners are damaged, or our computer systems, that could give us a error margin at the readings, or if they are totally damaged they wouldn't do a thing.
SFC includes that kind of things in the mission api. Cause there they could program the AI responses based on things like their BPV and system damage reports.

And its surely a cool topic to discuss. And an endless one.
Cause, it will be the most visible aspect of the gameplay after taking a spin in space with our ship in single player.

While the timer for the weapon is greater than 0 the AI would act more aggressively trying to take advantage of the fact that the weapon is still loading.  Once the timer reached, say 15, the AI would go into a defensive posture, ready to counter the Plasma Torpedo that could be launched as soon as 15 seconds.  The number can be updated through Tac Intel, so if it gets close enough to tell that the Player (or other AI) isn't charging their Heavies as fast as possible, it can reset the timer accordingly.  A threshold would have to be set, based on the AI's ship size (and possibly damage state), as to how much heavy incoming fire it would be willing to take.  So that if someone decided that they would just be charging one Heavy, or holding a single Heavy in reserve just to keep the AI on a defensive footing, the AI could determine, that it was willing to take a single Photon, even an Overloaded Photon, to close on the player while he's reloading the other three.  Or that that F-torp that's loaded and ready just isn't a big enough deterrent to keep my fully shielded cruiser from closing and hosing, but if I don't get in in the next 45 seconds, the Player will have that big nasty R-Torp ready for me...

This kind of mental exercise you did is very cool. And you could expand it to include more variables.
I also like do to it. We could ask us:
    How many enemies are there on the map?
    How far are they?
    Where are they going?
    We already scanned their systems?
    How strong they are?
    Are they damaged?
    They have the shields up?
    Weapons charging?
    Are they targeting us? How many?
    What it's more important in this mission? We need to destroy the player or the things that he need to protect or get?
    etc...

    Can we translate these last questions in a level of danger or threat?
    Can we say that we are in a wining position? Or its better to run away as fast as possible?
    What its the best thing to do at the moment?
    How we decide it?

[d4v1ks]

 

This remembered me an episode.
When i start playing the soldier of fortune game, many years ago.
In the first level, we start in a city, in a small street.
I take a look at the corner and see some enemies and start firing at them. I kill one and to avoid being hit by the other i hide behind the corner and get back a little to wait for him.
"I will kill him as soon as he appears, i thought"
But the street was a blind alley. Then i hear a noise. I look at the side. And for my admiration the enemy, instead of fall in my trap, he stayed behind the corner and throw me a grenade.
You can guess the end.
I just was not used to that kind of A.I. reactions, at that time. But it was fun for me. A new challenge.
And that is all A.I. is about. Make things fun and challenge.

[[UFP]Exeter]

And that is all A.I. is about. Make things fun and challenge.

That is the intent.

Sensors are in the design, along with a range.  The further the range the less effective.  We also have long range sensor that provide limited information.  We are also providing probes, that provide detailed information, and the possibility of detecting a cloaked ship.

[[UFP]Exeter]

Back to scripting, there i a way to allow scripting, allows greater control over what can be scripted, and eliminate the performance hit with scriptng parsers.

Write the code in C#.  Then scripting can be in C#.  And c# is by far easier than LUA (C based) or Angelscrit (C++).   All the moder would need it a copy of Visual Studio express C#, and it is free.   As for game development would set u back maybe a week.  As for performance I do not see that much of an impact.  The only thing to reinvestigate would be physics.

The way the scripting and missions would work is we create an interface that will call the missions/script.  The C# code could be set to overrride nearly anything.   As the script is written in C# it is precompiled in IL, the size is very small and easy to distribute.   The one drawback, unless distributed the source would not be available.  On the plus side, we can open up the graphics, newtorking etc to the modder.  Making the most scriptable/modable game ever.

This seems to be a solution to the debate between closed system vs wide open. 

[d4v1ks]

That can be done. And i'm almost sure that you can extended it even further. Just need to check some things.

[[UFP]Exeter]

And we are at the point where are requirements can dictate and steer us in the direction for our development language.

Also, as we have the license for the code for EAW, we could use that as a model for missions.  Of course improve it.  But we would not be starting from scratch.

[d4v1ks]

And we are at the point where are requirements can dictate and steer us in the direction for our development language.

Giving up of the native c++ project?
Or just talking about the script language?

[[UFP]Exeter]

No, but with the scripting and the level of scripting some want I was looking at a way to do it.

1.  Easy to use, well scripting languages are based on compiler languages, so the easiest would be C#, then angelscript, the Lua and finally python
2.  Desire to be able to mod almost anything.  other than c#, the others require parsers that converts the script into code.  SFC2 worked around this by having missions compiled into libraries.  If we did then, the mission scripts would have to be written in C++, unless we went to C#

Using C# as a scripting language, with native C++, is a real pain and the additional libraries and steps would make it very difficult to script.

But thee are trade offs.  C# can provide all that is mentioned as far as scripting, but we lose some of what we want in the models, graphics and physics.

Personally I think we continue with native C++, and Angescript and do what we can.  Right now there is nothing but old games and promises.

Then, the easiest would be to build a proper game using all of SFB.

[d4v1ks]

Have you thought on continue to use native c++ and use some interop with managed c++ ?
Then you could use, in your current c++ native project, the JIT net compiler to compile mission scripts wrote in C# or even Java script, Visual Basic or Visual C (managed NET languages).
The good thing is that missions could be in 2 variants, pre-compiled assemblies, or just plain text files in one of those languages.

This seems to be a solution to the debate between closed system vs wide open.

That would be a way to obey the above requirement.

The .NET plataform allows even to do something more advanced.
We could create a scripting language fully adequate to the needs of the game using the Microsoft Intermediate Language, which can be used within the same context above.
Hypothetically an idea for a remote future...

[[UFP]Exeter]

Yes I did look at that.  When you write a managed code library and call it from native c++, there is some performance issue.  Also, for this to work we would have to expose the C# classes as .COM classes.  No, this is not a solution. 

We would be better off going the route of SFC2, each mission is a dll.  We can supply a template and then moders could make their own full blown mission.  It would require knowledge of C++.  But this would provide a way for full control.

That gets me thinking, a script capability for moding the game, and some missions, but in the script indicate there is a dll to load, and then the game can load and run it.  And if no dll used, the field is empty.

So the script will be for values to change but a fullblown mission etc, could use a dll.  And the game will run the dll.

[d4v1ks]

Everything is possible i guess.
Depends on what you really plan to do in pratice.

[[UFP]Exeter]

depends on what we make the top priority.

1.  If ease of customization and the ability to craft fully detailed missions and control the game, then c#.  This will entail all mods to be written in C# (scripting)

2.  If we want a good game with mod capabilities and do not mind a slightly longer learning curve for missions, we can go c++.  This will entail a scripting language (angelscript) and ability to build complete missions (C++).

I just want pinions and why.  If I hear nothing then nothing changes.  I am putting the last of the information in the design and will continue development this weekend.

[d4v1ks]

Sincerely, i don't understand the concern with performance about the mission's scripts when they are performed at such a slow rythm.
I had a simple idea in mind of how the process would work, and i don't see significant reasons to change of opinion.
I see it as having 2 APIS.
One is related about the things we can track in the game, like the player/AI interactions, etc.
And the other is about the things we can call inside of the scripts, that are hard-coded in the game.
The event(s) would be loaded at start from the script's main function; would be tracked in the game one at a time(depending on the number of current objectives) to check (if they were/it was) fullfiled; and the the game would call the script's next step.
I gave an example of that:
1 STEP: Go to planet earth
      (1 minute traveling...)
      1st objective accomplished: Ship has reached earth. Call script's next step
2 STEP: Scan the planet
      (4 or 6 secs)
      2nd objective accomplished: Player used Ship's scanner. Call script's next step
etc...

You don't like of that kind of approuch?
It ressembles the logic used in many games. And its easy to implement with c++ and angelscript.
Its easier and fun for a person without any deep knowledge to edit. We can wrote it in a text file, load it ingame and test it.

[[UFP]Exeter]

I am thinking of the deatail of the missions in EAW.  All of the detail, like victory conditions, states for the AI, starting ships and locations.  All was in the mission which was built in a dll.

It may be that many years ago LUA was not advanced enough.

But there are two things going on, Missions and Mods.

From EAW a mission dll, was created form 30-40 files.  Each file had half a dozen methods.

If angelscript can handle this I am game, I just to not know

[d4v1ks]

Angelscript has some limitations, and its not the fastest script language around.
For A.I. and addons i would go for the DLLs alternative too. We talked about that some time ago.
Maybe we could give one of those missions' DLL the opportunity to interface with AngelScript and load custom text-based scripts. Would be a little slower,
but would give people the opportunity to play a little with missions without enter in big details.
What you think of it?
You could start creating the game with those targets in mind and add them after you made some progress on the game itself.
"Divide to conquer" is a good thing, to prevent falling in the trap of getting overwhelmed with the complexity of all the game details.
And you could produce and show some progress of the game itself to people.
In the end you could start to export some of the game funcionality to DLLs (3rd folder) to give people the oportunity to mod it.
Imagine the following...

Game folder --+---  Data -----+------------------------------------> A.I Folder
    (exe)          |                    |               1 or more DLL's with diferent AI approachs or levels of dificulty.
                     |                     |               Would give opportunity to mod the existing or add new ones.
                     |                     |               Inside the missions people could instruct the exe to load the A.I.
                     |                     |               they want to use on it.
                     |                     |               
                     |                     |
                     |                     +------------------------------------> Missions' Folder ------------------------------------------------------->Scripts folder
                     |                     |              (missions dlls. One of them would interface with angelscript to use              (missions (*.txt) made to work with angelscript)
                     |                     |        custom scripts made by hand on a text editor or a tool specific to the case)
                     |                     |
                     |                     +-------------------------> Bin folder (graphics/sound/etc funcionality)
                     |                                                                        (DLLs....)
                     |
                     +-- Addon 1 ---+--------------> AI
                                           |
                                           +--------------> Missions  ----------> Scripts
                                           |
                                           +--------------> Bin

[Starfox1701]

I don't think we are on the same page here because I think we are looking at mission design from the most difficult method of doing things. Wouldn't just be better if we built the ability to setup missions into the map editor?

[d4v1ks]

You are talking about creating the missions inside the game enviroment?
Cause its possible to produce an visual interface that would work in the map editor, to create/edit your mission and save the result inside the "Game\Data\Missions\Scripts" folder.
That tool would interpret the things you did in the Interface and wrote the accordingly AngelScript code translation. Then you could load, test, or delete it.
Most people wouldn't need even to know what is happening/happened in the background.

[[UFP]Exeter]

You are talking about creating the missions inside the game enviroment?

I had not thought about dong this.  I meant the game would load the mission when it was selected.

That tool would interpret the things you did in the Interface and wrote the accordingly AngelScript code translation. Then you could load, test, or delete it.

My concern is this:  With angelscript the game loads it at some predetermined time, compiles it internally and runs the script.  In theory this can do anything, and perform decently.  And we would need tons of code to detect errors, we would not have the control over memory or resources. 

The alternative, is the way SFC:EAW does it.  The writer for a mission would need the free version of C++ from microsoft.  We supply the template and project files, with instructions.  Then the mission writer would create the missions in the files, run the compiler and the entire mission is save in one dll file. 

We can go either way. 

I would prefer somebody else to look at both options and make the suggestion.

[d4v1ks]

And we would need tons of code to detect errors. 

During the load and compile process angelscript can give detailed information.
If some error happend it could say where the error was (line, row etc), etc.
Editing script files at hand would require some knowledge. But if we create a tool ingame for that process the resulting script would be almost error-proof.

[[UFP]Exeter]

hmmm, sounds like a project I worked on long ago, to take user data and generate the code for it.

Not sure if we want a standalone sript writer or have it part of the game.

But we will use Angelscript for missions and mods.

Now, we need somebody to learn it

[Starfox1701]

Well the way I see it scripting over hard coding in and of itself give more flexibility but using a language like angelscript is counter productive because the syntax is more symbolic being more closely related to  the base code. While it makes your life easier Exeter it ultimately limits accessibility to the masses because it is hard for them to read and therefore comprehend. Creating these tools like the map editor/mission scripter and the model property editor are a way to restore the accessibility without making your work that much harder and it makes the game more attractive. Hell we could even include option for modifying and creating new weapons and equipment scripts from inside these tools.

[Captain Adam]

.

[[UFP]Exeter]

So if I follow this correctly:   We have a mod/mission generator that builds the code.


Take a look at Civ 5 modding, depending on what you want to do, there are different tools:

http://www.weplayciv.com/forums/entry.php?15-Dale-s-Mod-Blog-Civ5-Modding-Explained

If we follow what StarFox  suggests, it will require some additional coding for the integrated mod tool.   This does cause me to think about C#, as major studios are using it for mod tools.  And to do what StarFox suggests, c# is already designed for scripting language.  If the game was done in C#, an integrated tool would only create the code and integrte it easy.  (compared to c++).

[d4v1ks]

If you remember sfc4 was introduced in the forums with a question about what would be the best language to write the game. Several days have passed till then. I dont want to believe that at this point a decision was not done yet. All these options and aproachs were discussed already.  Just make up your mind.

[[UFP]Exeter]

The suggestion was also made, a good one at that, to let our needs and requirements determine the language 

As I am busy at work and the finishing touhes on the desing, that decision is flexible.  I have spent time looking at scripting and modding.

If we had 10 volunteers to assist in C++ and 1 for C# that would make a difference, but what we have is 1 for C# and 1 for C++ that express knowledge but not much time to get involved.

But the decision needs to be made, so I am posting facts worth considering. 

But I will make the final decision the next couple days.

[[UFP]Exeter]

I spent some time learning some angelsoft, in general.  This is how it would work:
1)  we read the script file (c++)
2)  we compile the script
3)  we create a context
4)  we execute the script (including passing the parameters)
5)  we get the return parameters

This would work for us,  as we would have some kind of script telling us what to run when.

Angelsoft also has a tool for assisting with this process, that we could utilize.

So this will work and I have a general idea how.

And to keep this simple, each mission/mod will be stored in a zip file so all the files are the same.

[d4v1ks]

This would work for us,  as we would have some kind of script telling us what to run when.
So this will work and I have a general idea how.

That was what i tried to explain in the pseudo-code i gave without entering in those kind of details. 
I can imagine that now you have a better understanding of how would work the ideias i tried to gave you earlier.

[[UFP]Exeter]

I remember the ideas but I needed to get more details on how Angelsoft worked.  The concern was the game loop is running the entire game, and is needed for the physics, if the loop was controlled by the script language, we would have problem.

I am working on the details of the desing and plan to finish yet this weekend.  Then let it sit a week or so for input.  Then the design is locked.

[d4v1ks]

if the loop was controlled by the script language, we would have problem.

The ideia i had was exactly to avoid that kind of situation.
In the game loop, one of the functions in the mission script, would be called when we needed the next node of the mission tree. But this only when the objectives of the current mission node had been fullfield.
Also the Angelscript has a way of returning the control to the game loop if something went wrong in that particular function (a timeout).

[[UFP]Exeter]

If something went wrong in the script we would need to capture the error and do some exception handling.  I would rather not crash the game because of a mission failure.

As for exception handling that is one area C# wins hands down.  The other area is strings. 

[[UFP]Exeter]

Ok, I have startup data I was going to put into a database.  I am going to try and learn enough AngelScript to use that for the initial data.  And hopefully other data I need for the game.

[[UFP]Exeter]

There is an issue for the models.  To be able to load the model files, means knowing the names of models, textures, scaling, rotation, translation.   Based previous discussion, 3 textures, 15 pieces of data for each model. 6 races, the antagonist and 10 model each.   That is over 1000 pieces of data, and that is one line of code for each in angel  script not to mention the supporting code.

I did try it.

So I think the game data should be stored in a database. but the moders can use script to overwrite the data.  fine detail and only overwrite what the want.  We can go for an open database, with the disclaimer that changing the database is not supported.  With the scripting there should not be any need to, but they can look at anything they want.

Any thoughts, does this meet the open principle of modding that many desire?

[Starfox1701]

Why stick all that in 1 file? Wouldn't it be simpler for the game to load all the Object Data files at start and each file points to the  model and the model points too its own textures. Then it only loads the models and textures as needed and all you need is a master list file for all the object data files. In this context the object data file represents the script file for any map object ship or station.

[d4v1ks]

In my case i would create a folder named "models", and inside that i would create a folder for each race, them inside those a folder to each model. Then would do an recursive folder search to get the contents of each folder. The name of the model would be given by the name of the folder. Then for each model i would locate the files by extension. In the end you would get 1 3D model, 3 textures and 1 script per folder. In the script i would only create a small code snippet. And complement the code inside the game.

basedir = ".\models\"
Race = dir(basedir, DIRECTORY)
While race != 0
   model = dir(basedir & race & "\", DIRECTORY)
   while model != 0
      file = dir(basedir & race & model & "\*.X"
      r = loadModel(file)
      if r != 0
         file = dir(basedir & race & model & "\*.DDS")
         r = loadTexture(file)
         if r !=0
            file = dir(basedir & race & model & "\*.script")
            if file != 0
               script = "void load(*center, *rotation, *scale, *name) {"
               code = loadScript(file)
               if code != 0
                  arg[]=split(code, "\n")
                  for (n=0;arg[n] != 0; n++)
                     script = script & arg[n] & ";"
                  script = script & "}"
                  r = compileScript(script)
                  if r != 0
                     angelScript->executeFunction("load")
                     angelScript->pushArg(center, rotation, scale, name)
                     ship->race = race
                     ship->model = ...
                     etc...



Example of a script code snippet:


Rotation.X = 0
Rotation.Y = 0
Rotation.Z = 0

Center.X = 0
Center.Y = 0
...

Scale.X = 0.75
...

Name = "Heavy Cruiser"

[[UFP]Exeter]

I follow what you are saying but very inefficient.  A database is much more suited for for storing large amounts or raw data.   The database code is embedded so no database app will need to be installed.  The database will be read only at the os level, but can be changed if desired.  As the database is standard SQLite there are various tools to easily edit this.

I am thinking all the games raw data to be in the database, not just model information, but combat tables etc.
The game data required to even load will be stored in config.xml  (this stores the desired resolution, and the desired driver (Directx9, Directx110, Open GL)
Missions will be Angelscript

Mods, they can change whatever they want in the database or create scripts.  Once a mod is loaded,

Missions will use whatever is active, the base data or the Mod data.

The way I see it working:
Game starts, reads config.xml, then load the appropriate driver
Internal data table built (does not store the game data from the database, just pointers and flags)
Main menu, player can select to load a mod or a mission etc
     If mod selected, the internal data table is updated based on Mod script.
Mission is loaded and compiled
Mission runs, Mod and database are transparent.

The config.xml is working right now
The database is working right now
Finishing a test with angelscript.


My thoughts on this after all the discussion:
For missions, we use a scripting language.  At the moment that is angelscript.  If we get someone onbaord that already know LUA, we can change that easily enough.
for mods, if they want to change or create a new database, they can.  They can use scripts to change how the game works.  We will also create a mod tool, but they can do it anyway they wish. 

This is based on what has already been done.

Currently, I read the config.xml, to determine the driver and resolution, display a splash screen the once the background is doen, I go to a tactical screen and display 2 models.
The areas that have the structure in the game engine complete, select tactical screen background, event handler, display menus, load selected model data from database, create active model list, integrate with anglescript and physics.  The current state does not do much because working on the movement of ships. 

Problem is there is alot of behind the scenes work. 

[d4v1ks]

About the model information:

I follow what you are saying but very inefficient.

Inefficient, but very user friendly.
Just imagine. A person to mod the game would only need to create a folder inside one of the folders of the race they wanted. Them drag and drop some files (model, textures). And in the end, create a text file with a few lines of code or not (cause we could generate some default values for the variables based on the model previously loaded in the code).
To avoid what you call "inefficient" you could add a button in the main menu options called "Update" that would generate a list through the process i described above. Next time, if the list already existed you could skip that part.

Well, you could even use that read-only database as that list for a quick visual reference.
One good thing, is that you woldn't need to install any special tool to edit the database.

Mods, they can change whatever they want in the database or create scripts.  Once a mod is loaded,

I think the way that you mentioned, things could get messy. Imagine a missing file, a error on a field of the database. Something forgoten. Things could not be synchronized at all.

But its your call.

[[UFP]Exeter]

Guess some parts were not explained well.

A mod does not have to touch the database.  The information in the database can be loaded in a script file.   A moder can do everything in a script file.

However, if someone wanted to make the game into a Star Wars game, including the models, race names, 2D graphics, audio etc, such a detailed and comprehensive mod would have to hit the database.

I am not saying to mod the game you have to do script and the database.  That could be a mess, but rather both will be open.   

[[UFP]Exeter]

First I am not back stepping, but listening and trying to sort some things out.  Some would like the game to be very mod friendly. 

Option 1:  C++, Angelscript
Option 2:  C++, Angelscript and SQL database
Option 3:  C#
Option 4: C#, SQL Database

The language change iif there is one is irrelevant as I have structure and other systems built in both.  And the performance difference is negligible.  To reiterate, to switch would cost no more that a week , if that.

What I have been doing is reading ideas, discussing, disagreeing and then reevaluating based on facts. 

Some scripting differences.  Angelscript will only be able to script what is made available to it.  The API must be made available.  And it is easier that LUA it is still complicated as it is still C++ based and that includes pointers.   But,C# as a scripting language, is easier to understand, much like c# is easier compared to C++.  Also, a c# script can be imprted into the games assembly and makes the game wide open for moding. 

The  CS script, best example is CS_Script is C#, and as C# is easier to program in than C++, anyone with C++ experience will find it easy.  Plus we could make this the easiest game to script.  Plus C# has direct access to the database via LINQ that a moder could extract from the database directly.

Thoughts while I pull my hair out?

EDIT:  I like to pa-rouse and read and with the performance improvement in MONO, it is very possible, if things were done in C#, it could deploy to Linux, OSX and others. 


Decisions need to be made by end of week, as I have 2 days free (Fathers Day) to do as I like

But still, a highly modable game, supports scripts for extensive moding, and can run on Windows, OSX and Linus without much extra work would be really cool.

[Starfox1701]

So which of these will work best with the tools we discussed? Remember the true test of modablity is not if you can change everything up Exeter; it's if some guy off the street can coming and with 10 mins of instruction start customizing the game stuff to his or her preferences. All the scripting in the world means nothing if we still need a master in programing to understand it.

[[UFP]Exeter]

That is one of my concerns.  From a programming point of view, C is hardest then C++ and C# is easier.  Significantly.  So given LUA is similar to C and Angelscript is similar to C++, the from an ease of use, C# is easier. 

Actual, creating of scripts.  An editor is required and then the scripts need to be loaded and tested,  For LUA and Angelscript.  Unless they code their compiler the scripts will have to be loaded into our game.  First to compile without errors then to run.   Compiler errors will not be that verbose.

C#, one tool, a free Microsoft IDE.  The code can be built and compiled.  The intellisource also points our errors.  We provide a xml file of the methods they can access and the intellisource will help them get the names correct and check the parameters.  It would still have to be tested for runtime.  And no memory or pointer errors occurs as it can in the other two.

And if you know a scripting language, c# would be easy to learn, not so the other way around.



So from an ease of creating a mod, c# would probably be the best overall.

[d4v1ks]

If you are looking for the benefits of C# on his fullest strengths look out for the project "Roslyn" that is being developed by Microsoft.
Like, i told before, you don't need any script engine to work with C#. It has everything you need for that matter right now.

What is the Roslyn Project

http://msdn.microsoft.com/en-us/vstudio/hh500769.aspx

Current release (for Visual Studio 10 SP1)

http://msdn.microsoft.com/en-us/vstudio/roslyn.aspx

[[UFP]Exeter]

Yep, I am aware of the Roslyn Project.

The big question is what you and Starfox and anyone else that wants to speak up, think about c# in the aspect of an easy to use scripting language compared to LUA or Angelsript.

The one issue was the DDS texture format but I got that working this am.

[Starfox1701]

Lua is the Game industry standard for scripting right now. All the benefits you keep talking about are from the programers side. We need input from people who either know both sides or at least know these different languages front and back.

[[UFP]Exeter]

I have never scripted before at all.  I have hacked game code, but no scripting.

As for ease of use, LUA may be the industry standard, but I am not the industry standard developer

And it is possible to still use LUA of Angelscript in C#, but what I read says why?  That C# does scripting and is easier.

The only reason I say easier is because c# is easier, more user friendly to code in.  I lacks the requirements to knwo pointers and memory allocation, which is complicated.  LUA and Angelscript use them.  That in itself makes LUA and or Angelscript to create from scratch.

[d4v1ks]

I'm starting to think that you have no ideia of what you are doing... Sorry.

[[UFP]Exeter]

I have never done any scripting. 
As for programming I have done programming for a very long time.  The biggest was a quoting system for a factory, 2 year project, and I did the entire thing myself.

For me to make a decision on scripting without seeking other advice would not be wise.  And the requirements of the game should dictate how we do this.

So far, for moding I have been convinced to extend what I thought.   As there is still discussion, and I have time right now, I have not decided.  However, due to my lack of knowledge I have a c# program that I am testing the scripting capability of C#.

[Starfox1701]

Look what ever language we choose for the scripting needs to be dynamic, embeddable, and extendable. C# is not a dynamic language. If you use it you will have to either do all the scripting by yourself or get a scripting tool up and running very early that is a flawless as the game we are trying to make.

[[UFP]Exeter]

Good point Starfox.

I actually have a few hours I can work on this today, and need to be focused.

As for LUA or Angelscript, I do not care.  between those posing on this thread tell me what you prefer and we will use it.  I have verified both and built the libraries. 

I have a bug in my camera control I want to get fixed today.

[Terra_Inc]

The only reason I say easier is because c# is easier, more user friendly to code in.  I lacks the requirements to knwo pointers and memory allocation, which is complicated.  LUA and Angelscript use them.  That in itself makes LUA and or Angelscript to create from scratch.

Sorry, but that is just wrong. Lua has garbage collection, and I can't remember ever juggling pointers when coding. Angelscript I don't remember too well, but last time I checked it was garbage collected at least. C# was never intended to be a scripting language, being much more like Java in its overall architecture. So it will offer you few of the advantages of explicit scripting languages.

I think you are not fully aware of the advantages of true scripting languages.

That is one of my concerns.  From a programming point of view, C is hardest then C++ and C# is easier.  Significantly.  So given LUA is similar to C and Angelscript is similar to C++, the from an ease of use, C# is easier. 

Being based on C has no actual influence on the language. I'm not sure what you actually mean with that - lua is not in any way like C. Its table system is very different from C. If anything, it's a bit more like Modula. And yes, it is implemented in C, but so is Python. I'm sure no one would accuse Python of being too much like C.

And if you know a scripting language, c# would be easy to learn, not so the other way around.
So from an ease of creating a mod, c# would probably be the best overall.

For whom? The people creating mods will, in all likeliness, be the fans of your game. They will not be programmers. For them, understanding the concept of programming is already hard enough. If you know no programming at all, or only very basic concepts, learning a scripting language that is friendly to non-programmers will be easier than learning how to use a more complex language that has very little tools to facilitate scripting and modding.

[[UFP]Exeter]

Terra? What scripting language would you suggest?

[Terra_Inc]

Terra? What scripting language would you suggest?

Hm. I certainly don't claim that it's an easy decision.

I've modded several games through lua scripting, and if it's well done it's definitely newbie-friendlier than classic programming languages. It depends very much on how much of the game you write in or expose to lua, and in which way. For example, if you have your object definition code in lua it becomes very easy for people to modify objects in the game, and add new ones. You see this with many older games (f.ex. STA2) that it's super easy to change some values in a simple Key-Value data file, and the tables of lua are basically Key-Value, with the addition that functions can be values.
Mission scripting is a bit more complicated since it's mostly based on finite state machines, and that requires some knowledge of control structures etc. Still, it might be feasible even for non-programmers to experiment with that. (For an example how this could be done, check Megadroid's Mission Mod - it comes with a basic mission tutorial which shows how you can script missions. It's still a bit weird in some parts, because STA2 is so darn clunky.)

I personally would suggest lua, based on my positive experiences from the user's side. I can't really say how hard it is to implement though, as I've never done it. So take my opinion with a grain of salt.

[[UFP]Exeter]

Implimenting will be my problem unless another comes along

So LUA it is, and it is and the library has been built and is part of the code.

The game is heavily OOO in its desing, I took alot from C# as far as coding desing, s hopefully that will make it easier for LUA. 

[FRA.E.Kehakoul_XC]

Lookin at operation flashpoint and ARma could be helpfull,especially the mission designer and how scripts are used in it.
The Arma wiki could be a starting point.
For me their approach was always the best compromise between accessability and complexity.

http://community.bistudio.com/wiki/Mission_Editor

http://www.armaholic.com/page.php?id=1455

[[UFP]Exeter]

Definately will take a look at arma, as I do want a good balance.  However the game will be complex,because of what we are trying to do.  But it would be nice to minimize the complexity for mods and missions.

[Starfox1701]

I don't think we can really minimize the complexity simply because it is inherent in the nature of what we are tiring to simulate.  Best we can do is keep it easy for others to navigate and understand.

[[UFP]Exeter]

System requirements of Modding the game:

Working knowledge of LUA
Editor
Degree on Computer programming   

[Starfox1701]

As long as we do good commenting in the script files and document all the commands we will be able to release a modders guide with the game or shortly after it's done.

[Captain Adam]

.

[[UFP]Exeter]

If you get started now learning to program you may be ready

Seriously, I did some reading and altered my code design to friendly for moding with LUA.  The main game core, which basically has the game loop, graphics initialization and load all the other game objects cannot be moded.  But all the objects can be, which opens about 80-90% of the game open for potential moding

[Starfox1701]

I got this during the research part for anyone how wants to get a head start on learning the scripting

https://dl.dropboxusercontent.com/u/3697428/Programming%20in%20Lua%2C%20Second%20Edition-2010kaiser.pdf

[[UFP]Exeter]

Very nice.  I may get to it but probably not for some time

[[UFP]Exeter]

A little more research and experimentation.

This is possible:   (all been tested and verified.)   Is this a good wish list?
            LUA access about 70-80% of the game (maybe)
            An additional method thatrequires more programming knowledge but will have access to 95% of the code and it is faster  Should be able to leverage LUA more effectively
            Some game data stored in a database that the modder has access to.
            Simple mission scripts, LUA would be easier, but again the creators choice
            The proprietary medis stored in an encrypted zip but the modder can redirect to use his own media, and may place in zip at his choosing
            Mods may affect most game data, but not the specific game code.  ie physics behind collision may not be altered, but the bounding bodies for models can be.
            We will release a MOD editor to make modding easier, but  does not have to be used  (Mission Scripter)
            Mod testing to allow loading and debugging of mods.
            Mod loader to allow multiple mods in the game and selection of which one to use.  This requires the games base code and base data be intact

Is there anything else to add to the wish list?

[Starfox1701]

Well we still need a model property editor and I'd like to see a map editor/mission scripter if its doable. What are you considering proprietary media because most of the sound effects we will use come from the show already.

[[UFP]Exeter]

The Mod Editor I mentioned is also a mission scripter. 

Map editor does not really fit.  The game maps are 2d images with either overlays or models.

[Starfox1701]

And the proprietary media?

[[UFP]Exeter]

That is up in the air.  If anything we use we do not want to allow use in other works, encrypted zip.  Should not affect any mods as they can always add their own instead. 

[[UFP]Exeter]

I am not familiar with it but is python a viable scripting option?  I as as there is python and ironpython (managed code) and that would integrate well regardless.

[Starfox1701]

It has been done Bridge Commander used it and I know other games have too

[[UFP]Exeter]

do you think it would make a difference which one we used?   Other that hooking into the code I am in the dark and I can do either LUA or Python, though python appears more refined for embedding into our code.

[Starfox1701]

Well I have heard that Python is a more powerful system with a lot more libraries but is considered clunkier because of all the libraries.

[[UFP]Exeter]

hmmmm, we may not need the extra power of python.  If somebody needs that much ower of access they can get it using the C# scripting capability.  Otherwise LUA, I think.  I was reading about python but do not see any reason to change from LUA.  If anyone has other opinions, speak up as this will not be implemented for a while.