Worried about Global Script size

[AnasAbdin]

Hi all,

I am using AGS v3.3.0, March 2014
Global script is reaching 10KLOC and I have a hunch this is getting bad
I am expecting 20KLOC more within the next 2 months.

Should I be concerned about Global Script Size?
If not ignore the following

I am trying to create separate script files to ease the burden off the global script a little.

I have a GUI button code in the Global Script .asc:

Code: ags

function Button_Carter_OnClick(GUIControl *control, MouseButton button)
{
  gCurrentGUI.Visible = false;
  gAnotherGUI.Visible = true;
  global_variable = false;
  int var = 5;
  var ++; 
}

I created another script file 'CarterCode' and it has this function in its .asc:

Code: ags

function Button_Carter_New_OnClick(GUIControl *control, MouseButton button)
{
  gCurrentGUI.Visible = false;
  gAnotherGUI.Visible = true;
  global_variable = false;
  int var = 5;
  var ++; 
}

In order to lessen the code in the Global Script as follows:

Code: ags

function Button_Carter_OnClick(GUIControl *control, MouseButton button)
{
  function Button_Carter_New_OnClick(GUIControl *control, MouseButton button);
}

The boolean variable 'global_variable' is supposed to be invoked from this function and from other Rooms functions as well.
I am having so much trouble with imports and exports 

Finally after resolving my imports and exports in both .asc and .ash
I get this error message after compilation: Runtime error: unresolved import global_variable

Please, could you help me with this issue?

Bonus Question:
Would passing functions between scripts and importing/exporting variables and functions cause more processing load during run-time?

Thanks in advance 

[Cassiebsg]

just a quick check, where exactly have you defined global_variable?

You need to add it to the Global Variables, and it needs to be called exactly the same.
You don't need to import it, just define it there, and not in any script file...
Hope I make sense, and that am helping a bit here... otherwise just say so, and someone better than me will jump im to the help, am sure.

[AnasAbdin]

Thanks Cassiebsg this fixed the scripting issue and worked great.

Hope I make sense, and that am helping a bit here... otherwise just say so, and someone better than me will jump im to the help, am sure.

No. You're the best as long as you turn on the lights while typing

Still a little concerned about the load on the run-time processing with all these extra imports. The Global Script surely looks more tidy but what about all those 10s (probably 100s) of imports later?

[Gurok]

I was able to get the exact runtime error with the following:



If I drag GlobalVariable up the order of scripts so it is above TestFunction, the game compiles normally. You could also define the global variable in the TestFunction script. If you do the little export/import dance, it should be globally accessible to the module that contains it and modules that occur after the import in the script. If I define a global variable, I normally do the import in that module's header. AGS combines headers as it goes anyway. It's just a bit nicer and tends to avoid you running into these errors.

As Cassiebsg mentioned, the Global Variables section in Explore Project would solve this problem for you too. I tend not to use it because I don't define many global variables. Most of the time, I actually take advantage of AGS' module-level scoping to hide my variables from view in the autocomplete.

Your global script is getting large, but I don't think it's a worry. The size of the script certainly doesn't add to processing time any more than many small scripts would. Imports are resolved at the time of compilation, so don't worry about lots of small scripts either. The extra level of indirection, however:

Code: ags

function Button_Carter_OnClick(GUIControl *control, MouseButton button)
{
  Button_Carter_New_OnClick(control, button);
}

That's a function call every time you call that function. It will add a *tiny* amount of overhead to each global function defined this way. AGS doesn't turn it into a single function and I can't think of any HLL compilers that would. There's a tiny amount of housekeeping for maintaining the stack frame, particularly with object methods. Negligible, honestly.

I also wanted to show you that you're not alone! I have the same pedantry when it comes to maintaining my global script. My current global script looks like this:

Code: ags

#region GUI Stubs

/* Shared */
function Command_HideModal(GUIControl *a, MouseButton b) { GUI.Command_HideModal(a, b); }
/* gDisambiguate */
function btnDisambiguateOptionA_OnClick(GUIControl *a, MouseButton b) { GDisambiguate.btnDisambiguateOptionA_OnClick(a, b); }
function btnDisambiguateOptionB_OnClick(GUIControl *a, MouseButton b) { GDisambiguate.btnDisambiguateOptionB_OnClick(a, b); }
/* gInventory */
function gInventory_OnClick(GUI *a, MouseButton b) { GInventory.OnClick(a, b); }
function btnInventoryDown_OnClick(GUIControl *a, MouseButton b) { GInventory.btnInventoryDown_OnClick(a, b); }
function btnInventoryUp_OnClick(GUIControl *a, MouseButton b) { GInventory.btnInventoryUp_OnClick(a, b); }
...

I then have a module for each GUI, with one struct like:

GDisambiguate.ash

Code: ags

struct GDisambiguate
{
	import static function btnDisambiguateOptionA_OnClick(GUIControl *control, MouseButton button);
	import static function btnDisambiguateOptionB_OnClick(GUIControl *control, MouseButton button);
};

I hope this is food for thought on how you could organise things. I'm forever trying to make things as OO as possible. :/

P.S. I will reply to your PM soon.

[Adeel]

Personally, I wouldn't worry about the size of the Global Script. Functions can be easily shrunk and expanded. If I were you, I would shrink all the functions and open only the ones which I would need (and shrink them back again, when not needed). Besides, all my functions are easily accessible from the drop down menu.

Please note that I'm not in any way deterring you away from doing what you desire. I'm just stating my opinion on this matter. Since I'm not a clean freak, therefore I wouldn't mind trash lying around me (yes, I'm lazy too).

[AnasAbdin]

Gurok: Thanks for taking the time for this informative reply! That tiny overhead you mentioned it what's worrying. I will stick to the large global file then.

Adeel S. Ahmed: Yes sir. Shrinking is the best thing for now

[Crimson Wizard]

Gurok: Thanks for taking the time for this informative reply! That tiny overhead you mentioned it what's worrying. I will stick to the large global file then.

Not meant to offense, but this almost made me make facepalm IRL. I am getting upset seeing as people are worrying about things they should not, and keep using methods that cause them trouble.

There is a common rule in regards to programming optimization that saves time and nerves: do not worry about things until they actually happen.
The "tiny overhead" in your case could be an extra processing time so small that human being will be incapable to ever detect, something like a negligible fraction of millisecond.
That might be important if you had tonns of data processed in real-time, but when it comes to GUI, you should usually compare the program reaction time to user reaction. How fast a user would click your button? 5 times in second? 10 times in second? Even in worst case the user action would be like 1000 times slower than the program work. Meaning he or she would probably never even notice a "considerable slowdown" (in program terms), let alone "tiny overhead".


Also. Computers are meant to serve humans, not vice versa. Make computer work harder for you by introducing tiny overheads everywhere.
Err, I mean, organize your code as easier for you, not like easier for computer.

UPD In reply to this:

Still a little concerned about the load on the run-time processing with all these extra imports. The Global Script surely looks more tidy but what about all those 10s (probably 100s) of imports later?

The amount of imports will not add extra load on run-time processing. Whether you have 100 functions declared as imports, or 1000 - the script working speed will be the same.
If you are interested in technical details: when script loads in memory, it replaces all referenced function names with direct pointers (memory addresses) to them. The engine does not search all the function list every time a function is called, so their numbers won't slow it down.


@Gurok: there is also one rule I learnt - never mention "tiny overhead". The "tiny overheads" make people jumpy and reluctant to use new methods. The less they know about "tiny overheads" - the better.

[Dualnames]

Well, I've reached 19k on Primordia, and I ended up splitting some sections of it into modules, for my benefit. I think in H2G2 i reached 40k. It doesn't matter how much code there is there. Modularizing it helps indexing it and finding certain functions/variables/whatever easier. It's like for example having the entire tween module on global script instead of it being a module script separated into a script and a header, it won't delay the game, it will just make more of a mess of a code for you to read.

[shaun9991]

I think I'm up to like 20k already for 'The Legend of Hand' and the game is only about 20% done...my dodgy programming skills... but so far there isn't any noticeable issues.

[AnasAbdin]

If you are interested in technical details: when script loads in memory, it replaces all referenced function names with direct pointers (memory addresses) to them. The engine does not search all the function list every time a function is called, so their numbers won't slow it down.

Thanks for the information But to my defense -I hope- I was mostly concerned about running the game in older computers and mobile devices

Dualnames & shaun9991 thanks

[Gurok]

@Gurok: there is also one rule I learnt - never mention "tiny overhead". The "tiny overheads" make people jumpy and reluctant to use new methods. The less they know about "tiny overheads" - the better.

I did say it was negligible! I should have hinted more strongly. Like CW said, it's not worth worrying about. Fractions of a nanosecond. And also, as I said, imports are resolved at the time of compilation. Sorry, I didn't mean to lead you astray, AnasAbdin.

[abstauber]

I'm at 526k pure script, split into 34 modules
The game still runs great on an older Atom CPU.
Don't worry about speed, seriously

[Cassiebsg]

I would say that graphic resolution, amount of characters/objects/animations in a room have more influence into the game speed, rather than a bit of text, no mater how big that text is (okay, maybe if it's like 50G file, might be a problem )...

[Adeel]

I would say that graphic resolution, amount of characters/objects/animations in a room have more influence into the game speed, rather than a bit of text, no mater how big that text is (okay, maybe if it's like 50G file, might be a problem )...

I would hazard a guess that there won't be a performance impact on the game speed even if Global Script's filesize reaches 50GB, unless there's a scripting mistake. Compilation might get slow, though.

[Crimson Wizard]

I would say that graphic resolution, amount of characters/objects/animations in a room have more influence into the game speed, rather than a bit of text, no mater how big that text is (okay, maybe if it's like 50G file, might be a problem )...

I would hazard a guess that there won't be a performance impact on the game speed even if Global Script's filesize reaches 50GB, unless there's a scripting mistake. Compilation might get slow, though.

Game and room loading times might get slow.
Although I doubt AGS can load that much data at a time anyway.