Topic: Configuration and Scripting

[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.