Jump to content

Photo

Suggestion for script organization?

organizing organization

  • Please log in to reply
5 replies to this topic

#1 Mephestrial

Mephestrial

    Newbie

  • Members
  • Real Name:Jeremiah
  • Location:Wisconsin

Posted 29 June 2018 - 01:19 PM

I have multiple scripts in my quest and I've been able to figure out how to combine things, adjust things and even write a few quest specific stuff for myself, but I've noticed that its starting to get a super messy and some of the scripts do very similiar things that could be combined with a few if statements to separate out the varying effects. Do you guys have any tips or general rules that you follow when coding your globals, variables, npc scripts, etc..? I'm mainly looking for basic layouts for how people prefer to do their conditions and actions but any suggestions are welcome.



#2 Moosh

Moosh

    Tiny Little Questmaker

  • ZC Developers

Posted 29 June 2018 - 02:17 PM

For global variables, it's best to use arrays pretty much exclusively. ZScript only allows for 256 variables (local and global combined per script) at once, but arrays only count as one. So for this I recommend putting all loose global variables in a single array with constants marking what each index contains:

int G[1000]; //The Moosh Global Variable TM
const int G_MOVEBOOST = 0; //Link's current movement boost
const int G_PUSHX = 1; //X value Link should be pushed by
const int G_PUSHY = 2; //Y value Link should be pushed by
const int G_STICKX = 3; //X component of directional inputs
const int G_STICKY = 4; //Y component of directional inputs

Ints and floats are the same thing in ZScript so I usually just use int since it's slightly shorter to type.

 

For global script readability it's best to use functions for as much as you can. You can split every global script into three parts:

ScriptName_Init(); //Initialize variables on load/death/F6, runs before while(true)
ScriptName_Update1(); //Updates that run before Waitdraw() - Waitdraw waits until engine stuff such as Link's movement happens
ScriptName_Update2(); //Updates that run before Waitframe() - Waitframe waits until the next frame (1/60th of a second)

I generally avoid using local variables in my global scripts since only arrays and global variables can be modified by functions without using a return value. This is where that large global array trick comes in handy.

 

The global script is the main case I find where things can get messy. You want it to be structured so there's only a single while loop with a single Waitdraw(); and Waitframe(); so it will be compatible with database scripts. Adding more than that without really knowing what you're doing is the gateway to nightmares. :P

 

Hope some of that helps.


  • Anthus, Binx, coolgamer012345 and 1 other like this

#3 coolgamer012345

coolgamer012345

    🔸

  • Members
  • Location:Indiana, USA

Posted 29 June 2018 - 05:52 PM

If you're doing a bunch of complex stuff in the global script, putting all that stuff into a function and then just calling that during the main loop will help clean things up. It'd look something like this:

global script GlobalScript
{
void run()
{
while(true)
{
MyGlobalStuff();
Waitframe();
}
}
}

void MyGlobalStuff()
{
// stuff that runs every frame goes here.
}

A lot of global scripts work like this, so it's helpful to do this if you need to combine them.


  • Mephestrial likes this

#4 Mephestrial

Mephestrial

    Newbie

  • Members
  • Real Name:Jeremiah
  • Location:Wisconsin

Posted 29 June 2018 - 08:46 PM

Some pretty good suggestions so far that I'll put to use. Also thanks Moosh for the bottle scripts and map scripts. I've modified the bottle script to handle 6 bottles plus new bottle contents (poe souls, beetles, milk, etc..). I also made my own script to handle new bottle acquisition so that you always get bottle 1, 2, 3, 4, 5, and 6 in order no matter which order you find them. I learned alot by dissecting your work.


  • Avaro likes this

#5 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 30 June 2018 - 04:14 PM

I have multiple scripts in my quest and I've been able to figure out how to combine things, adjust things and even write a few quest specific stuff for myself, but I've noticed that its starting to get a super messy and some of the scripts do very similiar things that could be combined with a few if statements to separate out the varying effects. Do you guys have any tips or general rules that you follow when coding your globals, variables, npc scripts, etc..? I'm mainly looking for basic layouts for how people prefer to do their conditions and actions but any suggestions are welcome.

 

If you post your result, we could give you further pointers, using it as a base example.

 

In general, you don't want to run an instruction when it isn't needed, unless suppression overhead is >= the overhead with perpetual calls to that instruction.

 

Beyond that, whether you can trim down execution depends on your script logic.

 

If you value clean readability, t's usually best to break down instruction groups into functions, and function nests.

 

I see also that Moosh is now teaching my gospel on array access. ;)

 

Try to adhere to a uniform style for braces, and for identifier naming. Using descriptive identifiers on functions, and variables, will help to simplify debugging; as will the use of defined values to access your arrays.

 

arr[INDEX_PURPOSE] is always telling you what it edoes, while arr[5126] is meanngless unless you love memorisig arbitrary values.

 

I use the following style guidelines:

Tab indent.

Braces on their own line

......except for accessors and prototypes, which are always all on one line.

......while statement in do-while is on same line as $END for do{};

Constant identifiers: UPPERCASE

Global variable/array: LeadingUppercase

Global function:

......Normal priority: LeadingUppercase()

......Prototype: UPPERCASE()

Local variable, aray, or function: leadingLowercase, leading[], or_all_lower()


  • Mephestrial likes this

#6 Mephestrial

Mephestrial

    Newbie

  • Members
  • Real Name:Jeremiah
  • Location:Wisconsin

Posted 04 July 2018 - 11:51 AM

ZoriaRPG, I already use most of those style guidelines myself, except for the ones for Prototypes, but I'm going start using them from now on.

 

I am currently rewriting all the scripts in my quest because I have a lot of inter connectivity.

For example, I'm using a PegasusBoots script so I added some dash breaking bomb doors to Moosh's FFCDoors and that required a global variable to track when link was in a dash on collision with doors. I also added a special "context" button to my hud so that if you could dash it shows your boots, if you can lift a rock with the GBBracelet script it shows your current bracelet, if you can talk to a npc or sigh it shows a speech bubble, etc... 

 

That is three scripts right there that all talk to each other, I even skipped the Dash Item Pedastal script I made to make the dash more inclusive feeling.

All of this interaction is currently very hacky but functional, I just want to go through and clean up the way I coded that kind of stuff to be more minimalistic and easier to read/edit for future use.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users