Topic: Configuration and Scripting

[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