Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

FPSC Classic Product Chat / Scripting (FPI) Language

Author
Message
Rob K
Retired Moderator
16
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 26th Oct 2004 09:32 Edited at: 26th Oct 2004 09:33
There have been a fair few threads about scripting, so I'm just going to give you a quick overview of how it works at the moment - from what I have heard from Lee/Mike. It is quite possible that this is subject to change in the future. (Lee/Mike: If I have made a mistake, feel free to correct me.)

All scripts are stored in .FPI files which can be associated with certain entity actions. For example, an enemy would have one for when it is created, a main one which it runs through all the time, one when it shoots the player, and one which is run when it is destroyed.

FPI syntax is very basic, consisting of a series of IF-THEN-type statements (using ":" instead of "IF" and "THEN"). In an IF statement, you can test the value of a variable, and set the value of variables or call a function as a result:

eg:

:state=0,plrdistwithin=100:state=1

If run on an enemy, this script would set "state" to 1 if the player was withing 100 units of the enemy.

The flexibility of FPI scripts is mainly limited by the "functions" and variables that you can access within the IF statements, hence there is plenty of room for expansion. If it turns out that users of the Early Adopter (EA) release want more functionality or access to more engine data, then it may be possible for TGC to add it for release.

As far as I understand, FPI scripts are converted to a kind of bytecode, and any media referenced in them is loaded when the level is loaded. This makes running the scripts very fast. In order to keep the performance as fast as possible, FPSC assigns different priorities to different entities depending on their distance from the player, and other factors. So an entity on the other side of the level may only "think" once every 2 seconds, whilst an enemy busy shooting you is "thinking" all the time.


BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.
Torrey
14
Years of Service
User Offline
Joined: 20th Aug 2004
Location: New Jersey
Posted: 27th Oct 2004 06:45
They almost sound like the FCL file format, but Lee's own variation.

I do wonder if they have a nice organization to them? If someone writes a huge game would they have tons of these ai scripts in some directory all unorganized? Undescriptive filenames would make it even worse.
Rob K
Retired Moderator
16
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 27th Oct 2004 06:55
You can choose the FPI file names, so it is up to the user.


BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.
Mussi
16
Years of Service
User Offline
Joined: 27th Jan 2003
Location: Netherlands
Posted: 27th Oct 2004 22:14
are these IFs and THENs replaced by a ':' sign for performance reasons?



Specs: AMD Athlon 1800+, 256 DDRRam 266mhz, 80GB HD 7200rmp U133, Geforce4 Ti4400 128mb
Mnemonix
16
Years of Service
User Offline
Joined: 2nd Dec 2002
Location: Skaro
Posted: 28th Oct 2004 03:50
I dont think so, The scripts are compiled into some rudimentary bytecode anyway during compiling of the game.

The 3d chat is coming...
Rights For Traffic Cones!
Mussi
16
Years of Service
User Offline
Joined: 27th Jan 2003
Location: Netherlands
Posted: 28th Oct 2004 04:47
Then why not leave it at IF's and THEN's for reading comfort?



Specs: AMD Athlon 1800+, 256 DDRRam 266mhz, 80GB HD 7200rmp U133, Geforce4 Ti4400 128mb
OSX Using Happy Dude
15
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 28th Oct 2004 04:59
Because it would make it all convoluted, and slow down the reading speed..

He who knows the cat becomes his slave; he who knows the dog becomes his King.
Kentaree
16
Years of Service
User Offline
Joined: 5th Oct 2002
Location: Clonmel, Ireland
Posted: 28th Oct 2004 05:07
And if they made the scripting language to0 easy, people might stop using DBP because of it

AMD Athlon XP2800+
GeForce FX5200 128MB
1.25GB DDR 333MHz RAM
uman
Retired Moderator
14
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 28th Oct 2004 05:41
Making FPScreator easy is what its all about. From the overview of scripts around thus far - it seems that its AI scripting and the possibility of extending that is being set up as it should be.

From what I see things are being designed so that state machines are easy to understand with sensible descriptions of behaviours and so forth that one will be able to string together so that an enemy will enact instructions like the script of a drama - the kind of set up indicated will allow enemies to react to circumstances by choosing from a number of behaviours/functions in a decision making process. That is just whats needed.

The option of too many behaviors is not possible. The question is how limited will the choice be either initially or by extension whether from inclusion/updating by the FPScreator developers or by inbuilt capabilities for users to add behaviours.

As I understand it we will be given the ability to add new or influence behaviours via scripting, but will that be limited by not having access to source? I dont think we understand fully yet how this is going to work.

I dont see a need for users of a tool like FPScreator to have access to any code which should remain in the hands of the developers as its a RAD tool so we dont need to be spending time trying to create code stuff which the developers of the product could probably do better and much more quickly as they understand the underlying engine best. It defeats the oject of the tool, however that means we are reliant on the tool having as many in built functions as needed to cover all posibilities.

A big task and we know that wont be the case initially. If successful the product will be hopefully updated as suggested to accommodate missing functions and features as users request them.

Its a viscious circle I guess and hopefully everyone will buy a copy of FPScreator and help ensure its success. I am sure it will benefit all in the long run.
Rob K
Retired Moderator
16
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 28th Oct 2004 09:01
I think Lee chose those symbols to denote IF, THEN and AND because they are easier to parse.

Quote: "As I understand it we will be given the ability to add new or influence behaviours via scripting, but will that be limited by not having access to source? I dont think we understand fully yet how this is going to work."


You don't really "add new" or "influence" behaviours. Everything is controlled by these scripts, so you simply replace the relevant one with your own. There will be a fair few scripts provided, so you can look at those to see how they are written.


BlueGUI:Windows UI Plugin - All the power of the windows interface in your DBPro games.
uman
Retired Moderator
14
Years of Service
User Offline
Joined: 22nd Oct 2004
Location: UK
Posted: 28th Oct 2004 10:51
Thanks for that Rob,

It seems there will be a good deal of flexibilty, though I am not sure you are saying there is a limit to the number of scripts if we can only replace the code inside an existing script and not add any further scripts in number.

I guess it may not matter - dependant upon what exactly a single script can contain. How many functions or behaviours or just a single one?

Anyway I am happy just to wait and see what is possible sometime down the road when we are shown more development.

Thanks

Login to post a reply

Server time is: 2019-03-23 08:15:54
Your offset time is: 2019-03-23 08:15:54