Script Writing and Usage: A canine perspective

[DerVVulfman]

Script Writing and Usage
A canine perspective

Dear friends,

I am not a true guru of software code.  While I have a good understanding of some programming languages, there are times in which I play things by ear.  However, I hope and trust that you have enough faith in my experience to accept what I have herein.

Part of this document is for those using the editable software code herein referred to as scripts, and part of this is for those who craft or create the code in use.  Within the given sections of this treatment, I may meander between the two.  But that would be where there is a blur where usage may require editing or where the author of a script should understand how different scripts may interact with each other.

-- Your Resident Werewolf

Part 1:  Save Games!

Before you ask, NO!  This is not about actual 'saves' when you access the Load/Save screen while playing your demo.  Instead, this is serious call of action about saving your progress.  As you work on your project, whether it is a game or a piece of software, you will want to keep a backup of your work.

There have been times when adding numerous scripts may cause the game to crash, lose a valuable feature, or make your game otherwise unplayable.  At the same time, a scripter working on a new piece of software might notice that a feature he worked on suddenly stopped working, or never noticed that his script does work but only in tandem with other software.

So backups of your work are not only suggested in the event of a hardware glitch such as a PC crash, but are considered vital in bug tracing or error detection.  A simple but effective way to find what even causes a game to crash or a feature to suddenly vanish is by erasing different scripts from the project, obviously done once a backup copy of the project has been made.

*     *     *

Part 2:  Difficulty Levels

How easy or difficult a script is to use is a subject that is always on my mind.  As one who writes code, I always think about the person who is going to use my finished product.  I know that some of my scripts are grandiose and complex, but I try to make them as easy to use as possible.  Others I have written, much easier for the common end-user.  It is with this in mind that I discuss the differences between scripts and how troublesome they may be to use.

Whether a script was made with extremely complex calculations spanning hundreds of lines of code, or was crafted with a handful of statements, the game developer or end user who wishes to incorporate the script into his or her own game might find a script easy or difficult to use.  Differences may be subtle or astounding, depending upon what the script accomplishes or how it is intended to interact with the rest of the game.  

This subject is merely just a description of the various difficulty levels, and not a concrete absolute.  Also, there is no standard nor any requirement for any script, demo, download or forum post to thus describe their software with these headings.  

Okay, let's be honest.  If you download a demo and find it includes fifteen (15) scripts working in tandem, it likely isn't for the light/casual gamer.

Easy level scripts are typically ones that require no further interaction from the end user other than adding them into your project.  They run automatically and typically without any necessary prep work by the end user.  Or if there is any additional work needed, it may be a matter of simple edits to the game's database or by adding a mere comment into an event.

These scripts tend to be simple fixes to the game system.  Some of these simple scripts may perform actual repairs where an error or bug may appear, such as the ever dreaded and misunderstood F12 script-stacking issue.  Other scripts may handle issues game developers may notice such as undue lag in maps when a large number of active events are used.   And yet others may be written which changes the way in which damage is calculated.

Early to mid-ranged scripts are those that require little interaction from the end-user.  However, some editing of the game's database or the script is required, or the script may some additional resources for use.  Still, these scripts may also be those that run behind-the-scenes.  Because they require some interaction from the end-user, they are almost never bug fixes.  However, these are typically subtle enhancements or features that can affect gameplay or are something which an author wished to add or return to their chosen gaming engine.

If one were to use a script that changes how Hit Point Damage appears during battle, it may merely require the script and some supplied .png graphics.  If one was using a script that changed a map's current tileset, it could require that the end-user make a map event that ran a simple script call or command.  And if one wanted to affect whether some items can be barred from a map, there may be a section in the script where the end-user just adds the ID numbers of the pertaining maps.  Some interaction is needed by the end-user, but only to a limited degree.  Scripts of this nature could be considered supplements to the already existing system.

In the earlier days of RPGMaker XP, there were a fair number of mid-ranged scripts wherein the script's author gave the user instructions on how to edit the default code.  Thankfully, very few authors now ask that.

Medium level scripts are a step up from the above, sometimes expanding upon an existing system or sometimes being a new feature of its own.  The difference is that the end-user will assuredly need to perform changes to his/her database or map events, and perform some alteration to the medium level script in use.  Fortunately, most script authors create an identifiable area within their work where the end-user may make these changes or adjustments.  This is typically known as the setup or configuration section, and is usually at the start of the script itself.  Medium level scripts can be features that change the menu's appearance or adds a new skill effect to the database.  They may also be new features wherein one can teleport from one map to another if given a list of options, or a means to increase a hero's stats in a training window.  

When added to your list of scripts, ala the script database, Medium Level scripts should still be no more than one page including the already mentioned configuration section.  However, the end user will need to have some instructions on the proper use or implementation of the script.  Likewise, the configuration section, if one exists, should have helpful comments or descriptions on what can be changed.  At the same time, medium level scripts may require the use of outside resources, be it new icons for a simple menu system edit, or a new set of battlers for a script which changes the default battlesystem from a frontview (Dragon Quest) system into a sideview (Final Fantasy) system.  Yes, the end-user now needs to pay attention a little more towards these scripts, and some reading may be necessary.

Advanced level systems are obviously more complex than the previously defined works above, and tend to offer new features or enhancements to the existing game system.  Advanced level systems tend to take up more than one page within your database, and almost always require the end-user to alter the system's accompanying configuration section to suit their needs.  These systems too tend to require outside resources, and may be changes to the menu or battlesystem as described earlier.  But the need for outside resources may not be the case depending on what the advanced level script accomplishes or how it is used.  Still, the systems tend to give the end-user more grandiose options on how the gameplay will run, and the complexity of the system may make comparability with other script authors works tenuous at best.

Of these, only scripts that add new functions and features, such as a hero's journal or a particle effects system, may be immune to issues where another person's work may conflict.  If crafted properly, the system's setup section should be made self-explanatory and with plenty of descriptive instructions on its use.  At the same time, it may be necessary for the end user to also change aspects within their game's database such as how items or skills are named, alter or add new data fields to act as on/off tags to identify special skills, change tilesets in a manner so the map system behaves in a particular way, or the like.   At this point, the end-user now has to pay close attention to what he or she is doing when adding an advanced system, and how he or she is configuring it.  In some cases, the end-user accesses a demo if one is available, and begins their project with the demo as the base.

Expert level systems are not something novice level users should start with, but often do.  Not only do these systems require multiple pages within the Scripts's Database as the previously described Advanced level systems, but may also rely on the use of other scripts.  In this, Expert level systems tend to be a complete set of features rather than a single enhancement.  And because of that, it may be more difficult to use as the end user not only has to deal with the setup or configuration section of the Expert level system, but must also be informed about the configuration sections of the other scripts it may also rely upon.  And just as they are heavy with configurable options, they tend to be heavy with required resources.  But again,  that is not always the case.  And some level of comparability between this script and others needed was maintained by the script's author, but that depends solely upon what scripts he/she used to enhances the system or to make it properly function.  

Almost always, Expert Level systems are complex and highly detailed battlesystems or are an advanced menu system with extremely detailed graphic systems added.  And in all cases encountered, they are found solely within demo downloads.  End-users tend to use the actual demo to begin their projects due to the sheer complexity of the Expert level system, and will need to carefully study any instructions given within the demo project.

Unfortunately, not every script author writes instructions on how his or her script / system is to be used.  On the other side of the coin, not every end-user reads the instructions.  Therein, fault lies on both sides.

*     *     *

Part 3:  Using Scripts

First, let me state that scripts are not the basis for a game.  Without a decent map or set of events, you have no game.  Eventing has been a staple of the RPGMaker line since its inception.

Years ago, when RPGMaker XP first hit the market, not everyone knew what to make of the Scripts Database or what RGSS exactly was.  Outside of Japan, RPGMaker XP was a mere download and without instructions.  Yes, boys and girls, when it first appeared, Japanese gamers were able to purchase an actual Box Set version of the Ruby-Script using game engine, complete with an instruction manual.  So many outside of Japan began looking at the code and began making changes to the default scripts, noting their changes and publishing them within the gaming forums.    These direct edits to the default scripts that come with RPGMaker XP were the first scripts.

Fortunately, as time passed, scripters garnered an understanding of RGSS (Ruby Gaming Scripting System) and developed new techniques and a form of scripting etiquette.  There is that, and a whole host of custom scripts from Japan appeared which likewise showed western scripters the proper format and usage of scripts within their system.

When you add your new found script into your Script Database, you typically add it between the scripts named "Scene_Debug" and "Main".   The script named Main is the very first script within the Scripts Database that is run by your RPGMaker project.  It runs constantly, performing a check to ensure the player isn't exiting the game, and tends to pass game control to the Title Screen.  As the RPGMaker executable starts, it reads the scripts top-down until it finds Main.  So any script, code or set of notes placed below Main is ignored.  

Yes, anything you have above Main must be properly coded or encapsulated in RGSS code without error.  But you can put notes of any sort without problems below Main and it won't give you an error.  Nothing below Main is executed.

Nearly every script begins with a top header.  This displays the name of the script, and most often the name of the author, the script's version number and when it was written.  Along with that, the header may have a set of instructions, be it small or large.  It is extremely bad form to delete the header from a script.  While it is no longer happening to the same extent, some scripts were posted within gaming communities with the headers removed while the forum post author claimed to be the creator of the script.  Plagiarism was a bit more rampant a decade ago.  Again, that doesn't happen often.  And you may have need for the author's name as well as any instructions written within.

Also, do not delete the comments in a script.  You may think you're cutting down on the game's filesize.  But you are also removing helpful hints and guidelines which may help you to identify what a particular routine in the script does, or how it goes about running.

Does the script have a section which you need to edit?  Does it have a configuration or setup section?  Chances are, there is a section in your script that relies upon the end-user to make an adjustment.  These sections should be identified by the script's author and tend to be at the top of the script, below the top header.  Very rarely does the instructions within a script tell the end-user to go to line **** to perform an edit.  While commonplace a decade ago, it is now common for the top of the script to have a section devoted to the end-user for his or her personal adjustments.  Or if the feature being added is a script system which uses multiple pages, the system will usually have its first page be devoted to the system's setup.  

Unless the end-user actually knows what he or she is doing, it is unadvisable to ever alter a script outside of the areas the author set aside or noted.

*     *     *

Part 4:  Game Objects:  It's not working anymore!

Have you ever ran a test on a game and saved your progress, and tried out a new script only to find your game crashing?  It may not be the new scripts exactly.  It may be your saved game.

When you are running your game or project, you are running a series of scripts that access the same data files you're altering with your project's editor program.  When the game begins, it loads the data and stores it within global variables that are referred to as game objects.  Such objects are the variables of $data_items, $data_actors, $data_troops and the like.   And because they are global variables, they can be accessed by your scripts at any time.

But there are other game objects that are generated when you start your game.  They too are global variables and are created in-game.  Such global variables are those of $game_variables, $game_switches, $game_actors and so forth.  While there exists both a $data_actors and a $game_actors, the similarity ends between the two.

The $data_actors object (or global variable) is an array.  But more specifically, it is a collection of data stored in the Actors.rxdata (or like) file in your project's data folder.  But the $game_actors object is also an array, formed from the Game_Actors class which uses records itself from $data_actors.

Again,  when you start a new game, you create these game objects.  But more to the point, when you save your game, you record the data of these game objects into your saves.  And when you load a saved game, you reload the game objects.   Every switch that was turned on, the hit points of your lead actor, the position of the player, and even the location of every event of every map in your game is stored for retrieval.

But some scripts that add new features also adds new game objects that also get generated when the game starts, and thus recorded in your saved games.

OOPS!  That could cause a problem, right?

A script that creates a new game object will do the following.  It will create the object when the game starts.  It will record the object when the game is saved.  And it will read the game object from the saved game when the game is reloaded.  But if the end-user is attempting to load an old saved game that does not have the new game object a script is looking for, you run into a data crash.  For some, it will be a 'Scene_Load' error, but that is depending upon your RPGMaker (or like) engine.

It may not be enough to just start a new game and re-record your saved game.  Depending upon the script, you may need to actually delete the old saved game from your project.  This may be necessary if you have a custom script that reads the saved games prior to displaying them for the player to choose.

So watch out.  It could just be your old saved game files are the problem.

*     *     *

Part 5:  Oops!  Script Order Conflict.

When some authors write their scripts, they may not think about anything except their own work and how it relates to the work of another scripter.  At the same time, another script author may write code that adapts to other scripts.  Herein, we may run into an issue where scripts may not play well together.  Or if they do not, some extra help may be needed or called upon.

Hey, remember what I said earlier in 'Part 1:  Save Games'?  This is one of many reasons to keep a backup.

When it comes to writing code that alters the default scripts already within your Scripts Database, there are two methods.  The first method of altering the default script is where the author takes the code and rewrites it in a manner that overwrites the old code.  The second method to alter the default script is where one uses a technique which attaches his/her new code to what is already existing.  Usually, the second method produces a much smaller script which accomplishes the same thing.  But while it is preferred that the author use the second method to merely attach his/her code and leave the original script untouched and functional, it is not always possible.

While not always the case, the problem with many script conflicts arises where a script performs a full rewrite of a default script or script method.

Now I'm talking a bit more technical, using phrases such as a 'method'.  A method is a block of code that does... something specific.  Other languages calls this a function or subroutine.   You usually see a method in a script defined in a class like  'def refresh'.  This 'defines' the refresh method (or subroutine).

If you recall what I wrote within 'Part 3: Using Scripts ', the RPGMaker engine reads the scripts within a top-down method.  It reads all the default scripts, which should be the first scripts within the project, and then should access the custom scripts you added just above Main.  This hexarchy of how you add your scripts is what it known as the script order.

If the RPGMaker engine reads a default script such as Window_Status, it is reading the script which includes the 'refresh' method which draws the actual data for an actor in the status screen.  But if the RPGMaker engine encounters a custom script further down that has its own Window_Status script which 'attaches' new code to the refresh method without actually rewriting the method, that new data will also show in the status screen.  The same can be said if you used a custom script which rewrote the entire refresh method in Window_Status with the new data.  This is the top-down methodology, reading the first set of scripts, and then seeing what is added or rewritten.

However, an issue may appear if you have two different custom scripts that dealt with the refresh method within Window_Status.  And this is where script order is concerned.

If your custom script which attaches new code is placed above the custom script that rewrites the actual refresh method, the RPGMaker engine will first read the script that attaches the new code and then reads the script that rewrites the refresh method.  As RPGMaker works top-down, the last thing it encounters is the rewrite, and the first script's refresh method code will be ignored.  However, put the two custom scripts in reverse order so the second script encountered is the one that attaches the new data to be rendered, and you get a status window with the data from both scripts combined.

So guess what happens if two Status Window scripts actually rewrite the same 'refresh' method.  Yep, which ever one is further down the list in the Scripts Database takes hold.

If you have an issue with scripts not working together properly, it may just be that you need to shuffle your scripts around where a script that performs a rewrite is encountered before one that attaches new code.  This is predominantly the case where menu or battlesystems are encountered.   If you have a custom menu system, you would likely have add-ons which handle the party order or customized equipment placed below so the new features attach to the existing custom menu.

But if you have two scripts with methods trying to overwrite each other, a separate patch which combines the two methods may be needed.   Said patch would be a separate script pasted below both containing the code of both combined.

So basically, one script may be interfering with another script, and changing their order in the Scripts Library may solve the issue.  Just move one below the other.  But if that doesn't do the trick, you may need to write a bit more code to combine the two and fix the problem.

*     *     *

Part 6:  I Hate it when Scripts Argue!

As an end user, this is something that you "shouldn't" have to worry about.  But unfortunately, you do.

Once and a while, you may be trying out new scripts in your project and run across popup message that resembles:

Script 'Game_Event' line 212: ArgumentError occurred.
wrong number of arguments(0 for 1)

This is an error where a 'method' within the game is expecting to receive data to work with, and isn't.  Or the 'method' is just not getting all the data it needs.

Yes, I'm talking about methods again.  And again, it is another way to say subroutine or function, or a bunch of statements collected together to perform a specific job.

When a method is defined, it may be set up to be standalone or to have data/values passed into it for use. These values are typically known as parameters or arguments.  And your typical refresh method within Window_Status, Window_Skill or Window_Item have no such arguments passed.  When another script wants to redraw those windows, it just runs 'refresh', and that's it.  But if you look at the 'start_tone_change' method within the Game_Screen class, you will see it is followed by a set of parenthesis with two arguments within: color and duration. So when this method is executed (in the Interpreter class), it executes the method with two arguments attached.

I created the above error message by adding an argument value to the 'update' method in Game_Character.  When the Game_Event class tried to run it.... Boom!   Game_Event relies on Game_Character, but that's another story.

Now I know what some people are thinking.   "How can I have the wrong number of arguments?  If the window only uses four  to define it's shape, where did this fifth one come from and why?"

Once and a while, a scripter may alter a method in a class, adding a new argument as a special switch, some extra data like training points, or the ID or data of an actual actor or battlesystem enemy.  More often than not, the author of a script makes allowances if the end user has another script which may attach code to the same method altered.  Other times, the end user may not be so lucky.

I for one made allowances years ago with my Animated Battlers system as it worked with a very famous (or infamous) Japanese battlesystem which had itself added new arguments to methods within the battlesystem code.  However, it was able to work without the Japanese battlesystem as I let it recognize a temporary value in place.  Oh, there are so many tricks.

If you are having problems with this type of error message popping up, guess what?  It could be a case where you can change the script order by moving the offending script further down.  Hopefully, the author of the script which increased the number of arguments in a method merely 'attached' his new code in the same way I discussed in 'Part 5:  Oops!  Script Order Conflict'.  But if he didn't, and created a whole new rewrite of the affected method, then you have a problem.

And if that's the case, another patch like the one I mentioned earlier may be needed to handle the issue.

*     *     *

Part 7:  He Reinvented the Wheel?

Sometimes, two scripters may have the same idea and may make their own scripts to do the same thing.  Yeyinde made his Fog of War script a decade ago, while MechanicalPen crafted his own in 2018.  That, in itself is fine.  And there are many scripts which people have written that add new features to the existing default battlesystems.   Sometimes, there could be as many as five different scripts which create the same skill or item effect and will work with the same default menus.

However, there are occasions when you try a new set of scripts and discover nothing works with it.  The script you wanted to use doesn't even appear to function.  And when you look to see why, you notice that one of your fancy new battlesystems doesn't even use the main system that performs the hits!

OMG!   He reinvented the wheel!

There have been many scripters who decided to change the way a major system functions, bypassing and skipping generally recognized methods, or by creating a whole class.  It would be very disappointing to finally find that spellbook script which lets you open the book in the Item menu and learn new skills, only to find that it neither brings up or adds the new skills as the menu system now uses a Window_Item2 and Window_Skill2 set of classes.

This is more prevalent within menu and battle systems than anything else.  And the above mentioned scenario did occur with a menu set which I personally rewrote to use the standard class names after seeing that the original author had no actual need to make totally new window classes.  Insofar as rewriting the default battlesystem, Enu's Tenkantai XP battlesystem which was ported over from RPGMaker VX would be the closest as it actively bypasses several method within the 4th action phase and uses its own unique damage calculation systems in Game_Battler.  Yet neither it nor Cogwheel's RTAB strayed away from the Scene_Battle class itself.  Only special battlesystems such as a Tactical system by GubiD or an ABS by Near Fantastica would qualify, but neither were meant to be rewrites of the default system at all.

Most scripters base their add-ons upon the default scripts.  So it's no wonder the various add-ons won't work on an Expert Level System that has been overhauled or rewritten.  You have to hope that the author of the system made enough add-ons of his own to sate your appetite, or that it was written to be compliant enough with the addons you want to use.    Yeah, right.

For this, you really do not have much choice but to sit down and really study Ruby if you want to keep those rewritten systems.  As none of the default-system using scripts will work with your custom-class ridden menus, you will either have to adapt the custom scripts to work with your menus, rewrite your menus to use conventional class and method names, or just get a new custom menu set.  And insofar as a battlesystem, that depends on how good you are with performing edits to your new  battlesystem add-on scripts

Er, I did suggest NOT editing any scripts unless you know what you're doing.

Obviously, these would qualify under the label of Expert Level Systems as I so described at the beginning of the article.

Hey, scripters?  If you're trying to make a whole new menu system, don't go and create whole new classes and methods.  It is usually unnecessary.  I mean, if you want other scripts to work with it, use the default scripts as the basis.  Otherwise, your system is going to be very lonely.

*     *     *

Part 8:  You missed the Convention?

Going back years, there have been many changes to the way people made scripts, initially from jotted notes and posts on what to change and where, to intricate and methodical systems and plug-ins which were being promoted by members of a gaming forum.  For some readers who have a lengthy history of Ruby scripting, they will obviously recognize this as the RMXP SDK (or RPGMaker XP Standard Development Kit) which was a valiant attempt at making scripts more compatible with one another, but suffered from forced incompatibility with other's works and lack of promotion outside its board.  Still, a number of the principles which those of the RMXP SDK team continue on and hold true.

Yes, you just entered the Scriper's Zone.

Say what you want about the RPGMaker XP SDK.....

It sucks.

Bite me.

Gimme a break.

I can't work with it.

Does it come with pickles?

Er, what?   Okay, enough ranting.   The RPGMaker XP SDK required people to use it's core system, which broke the default scripts down into smaller and more manageable pieces, but had a drawback in that they kept updating and changing it so earlier SDK scripts did not work with later versions.  That in itself was my pet peeve.   Sure, the idea of breaking massive methods like the typical 'update' method in various scripts into smaller portions is a great idea.  And to be honest, that is one of the things being worked upon elsewhere.  

But one of the things to come out which has carried on amongst many members is the scripting conventions or standards.  I will not attest to hold true to them all, I have some of my own.  But I will actively cover the ones they put forth, or give adaptions since this was part of their SDK and they had some fairly entertaining tools that not everyone here would use.  All of these, mind you, were covered in Section 4.0 of their SDK's documentation.

*     *     *

When it came to scripts, they were all required to begin with the following header:

#==============================================================================
# ** Script Name
#------------------------------------------------------------------------------
# Your Name
# Version
# Date
# SDK Version : (SDK Version Number) - Parts #s
#==============================================================================

Yes, this is sort of like the header I use, though I do question which came first.

One thing the SDK team didn't consider was a hard-fast format for the date itself.  There have been many scripts where they entered 01/04/06 and you just couldn't tell if it was April 1, 2006 or January 4th, 2006.  Personally, I recommend adding a format key like so (mm/dd/yyyy) after your date.

As towards the inclusion of comments within the individual methods of a script, it is typically recommended to have a descriptive single-line comment before each statement or block of code.  However, it is not an issue if very short comments appear on the same line as a line of code if space is permitting.

And if you are forced to actually rewrite a method, the SDK recommends putting comments before and after the newly added code.

*     *     *

Where  the different classes are concerned, the RPGMaker XP SDK requested naming consistency.  In this, they supplied the descriptive list below:

Data      - Any class that defines database information
Game      - Any class that defines specific game data for specific session
Sprite    - Any class that defines a specialized sprite class
Spriteset - Any class that defines multiple sprites
Window    - Any class that defines a specialized window class
Arrow     - Any class that defines a specialized arrow class
Scene     - Any class that defines a specialized scene class

Yes, that pretty much covers it.  I mean, who is going to make a custom HUD script and name the class which holds the window contents 'Shirley'?  I mean, calling the class 'Window_Hud' makes a whole lot more sens and certainly understandable if you're giving a friend the script to analyse.  Yes, you can give a class any name you want (even Shirley), but it does make it easier for the end user if there was a situation.

You already know that a method is set of instructions that are run, basically known in other code languages as a function or subroutine.  A class is a step up from that.  In a nutshell, a class is a collection of methods.  It isn't the largest of the 'collections' mind you.  A module is the largest of the coding structures, able to hold multiple classes.  As an example, look at the RPG module.  It holds various classes like the Tileset class, the Sprite class, and so forth.

*     *     *

As far as game variables and values passed throughout your game, they basically recommend that you be descriptive and not to try and reuse an already existing default value.  I can certainly go with that, especially since you don't want to change a game value in use for something else and botch your whole system up.  And they recommend cutting back on class and global variables.   Of that I was fully aware once it was determined that global variables use more resources (memory) than instance variables.

Definitely do not use global variables for a configuration system.  If you want or need to use values that can be read by every class in your project, use constant variables.  Even these use fewer resources than global variables.

*     *     *

Alias:
(noun) - A False Identity.
(noun) - Computing an identifying label to access a file or program function.

The next thing that the RPGMaker XP SDK covered were the use of aliases, which is used to allow a script author to add new code to an existing method.  The alias command is a tricky little system, allowing you to take an already existing and defined method and giving it a new name.  Hence, why the command is named 'alias'.  And the manner in which you use the alias command follows the following format:

alias new_method_name old_method_name
-  or  -
alias_method :new_method_name, :old_method_name

Now some of you are probably thinking "I thought the alias system allows you to add code to a method."  Well, yes.  Yes it does.  But what you are really doing is renaming the old method and giving it a new name, and then making a whole new method and then sticking the newly named method into it.  Pretty much like this:

alias new_method_name method_name
def method_name
 my_new_code
 new_method_name
 some_more_new_code
end

Rather ingenious, isn't it?

Using the alias command in this manner is much more preferable to overriding it.  And since using this method allows you to avoid overwriting previously existing methods, it increases comparability with other scripts.  Still, the SDK team wished for a standard when it came to the new name for your methods.  Their standard included the scripter's name, the name of the script, the name of the class within the script and finally the name of the method, or:

 
yourname_scriptname_classname_methodname / yourname_scriptname_methodname
 

Yeah, that's a bit long.  Still, it is more descriptive than making an aliasing a method and giving it the name fluffy.  Also, their method, while long, does avoid an instance where you accidentally give two methods the same name.  That is definitely not recommended.

*     *     *

They talked about strings in the RPGMaker XP SDK, pretty much suggesting that one should use single-quotes ('example') in their code, rather than double quotes whenever possible.  This is because single quote expressions use less processor time than those of double-quotes.   Still, one does have the need for double-quote expressions where string data is substituted, or if your string text requires a single quote for a contraction.

*     *     *

And when it came to line length where the code goes past the right margin, there was plenty to say.  They certainly didn't want to force the end-user of a script to scroll a script sideways to view its contents in the script editor.  Instead, they recommended that the lines of code be broken within certain guidelines.  

For those unaware, it is possible to have a line of code broken and continued on the next line.  Such breaks can occur after a comma or mathematical operator, and it is recommended that the continuing code appear indented with the rest of the line of code.  As an example, let me show you a line from Cybersam's Sideview battlesystem v 2.5:

@spriteset.enemy_sprites.enemy_pose(@weapon_sprite_enemy)

This one line of code could easily have been written like so:

@spriteset.enemy_sprites.
enemy_pose(@weapon_sprite_enemy)

Thus, it wouldn't go beyond the right margin and force the reader to scroll the window horizontally.

To be honest, I do add a little extra margin to the subsequent lines myself.  But that's my style.

*     *     *

The SDK team also talked a bit about the use of blank lines to make scripts more legible, as well as the use of blank spaces.  They were definitely keen on proper grammar, having a single blank space after every comma in argument lists, and after 'binary' or math operators  (such as + - * / ).  And the SDK team also touched on using parentheses liberally throughout a script, especially when dealing with math operations.  The use of parentheses certainly makes it easier to understand if you're not clear on operator precedence (or which comes first... addition vs multiplication).

They turned their attention to Constants, or values that do not change at all during gameplay.  They take up less resources than traditional values and I like using them for configuration systems.  Some typical values that would be classified as constants would be if the coder made a constant for PI (3.14159...) or held an array of unchanging values like the CHARACTER_TABLE array in Window_NameInput.

Usually, constants are defined with all its letters capitalized, or have at least one capital letter.   So don't go and make game values with capital letters, otherwise you might have an unexpected glitch.

And lastly, they talked about version numbers and their preferred guidelines.  But the funny thing is, the person who defined their version number system actually disliked the SDK itself.  

As towards version numbers, they preferred the format of :  A.BC or A.B.C
* A = Main Version or Rewrite
* B = Additions or modifications
* C = Bug Fixes

I stray from this format myself, just adding 0.1 to my initial version for each calculated modification and/or bug fix.

*     *     *

In a nutshell, the SDK team's guidelines for proper coding extended towards cleanliness and ease of reading scripts while adding proper notation for anyone who wished to read or study the script.  And simultaneously, they were stressing conformity with a ridged naming standard and standard for class names, variables and the like, while communicating to its users the need to make their software compatible with one another’s'.

Good guidelines in my personal viewpoint.  But they just blew it by the constantly changing versions and updates to the SDK package itself.  I mean, they basically tried to 'Reinvent the Wheel' over and over again.

Yeah, I think I covered that issue in 'Part 7:  He Reinvented the Wheel.' Didn't I?

*     *     *

Part 9:  “Data! data! data!" he cried impatiently. "I can't make bricks without clay.”

Woof... that was actually from one of the Sherlock Holmes novels, not just from the Robert Downey, Jr. movie.

Among the Advanced Systems that you may find or wish to craft, some may require extra data that will not be stored within the game's database.  Some of these advanced systems may include a library or a more detailed description of monsters or villains encountered.  Other advanced systems may be a quest menu which elaborates the missions the player must perform.   The lines of data may be excessively long, or may be short but numerous in quantity.  Whichever the case, the designer of the script system felt that there was a need to store this data in a manner less than typical.

One means to store all this excess data is by way of a separate page within the Scripts Database.  Designed to function much like the configuration section of a script or script system, it is within the game's project itself.  And because it is within the game's project, that it has the least drawbacks.  Perhaps the only drawback there is with this method is that you are limited in the number of available scripts one can insert within their Scripts Database, that limit being 999.

So who is going to have a thousand scripts in their game?  Oh, wait.  Werewolf shutting up.

The other means to store data for such a system relies on an outside file.  And for many scripters, this has been a text file.  But this holds a couple of drawbacks, first and foremost is that it can be opened up with easy by the player and altered.  Were this text file a means to control aspects of the game, this would be a serious cheat.  And were the text file to hold story content that is meant to unfold, this too would be a serious cheat were the player to be able to gain access and read it.  Another drawback that a text file holds is that it will not be compressed if one wished to create an encrypted project.  Much like the audio files within one's project, they are separate and uncompressed.  However, a third and separate drawback is that text files are not packed away with the rest of a game's project if one uses RPGMaker's native encryption system that creates a self-extracting .exe file,  

For those who wish to opt for external files, but also wish to avoid the pitfalls of text files, there is a solution.  One may wish to consider having their outside file encoded in the same format as that of their project's data files.  For a game being developed by RPGMaker VX, this would be an RXData2 file and stored within the game's data folder with all the other game data files.  Properly encoded, this file would encrypt with the rest of the developer's game and would be packaged up if using the editor's native packing system.  Such a system does take more effort to craft.  Quite likely, the scripter would need a means to take a text file and convert it into the game's data file format, and later convert it back into text format.

In any of these, the software developer (that's you, Mr. Scripter) should take great pains to ensure that it is easy for the game developer (that's you, Mr. User) to know how to create the data and/or convert the data into a format that is usable.

*     *     *

Part 10:  Know your Job.

In closing, whether you are a script user or one who writes code, you must pay attention. The purpose of custom scripts is to modify the default game system to do what you will. But clarity on the script's function and what users desire is a must.

To those who use scripts, I suggest that one needs to have an understanding of some level.  The more complex the system may be, the more of an understanding of the language used is recommended.  This would be of an assistance were a problem to be encountered if the author fo the code is not present.

And to those who craft the systems, it is imperative to realize that others will need an understanding how the system written is used.  A simpler system requires little in instruction while more complex systems have need of detailed documentation.  

Clarity is a must, whether one requests a piece of code, claims that something is in error and needs help, or makes something that the user must alter to suit their game.  

For a request, one cannot just say they want a system like the one in 'Fred's Revenge', this assuming there is a game with that title.  The petition needs information on the system itself as those reading the request may be unfamiliar.  What does the system look like and how it functions is a must.  A picture of the screen, what one would may consider a mock-up, is always helpful.  But with all this, it is the requester's job to be as thorough as possible, and explain their request clearly and in a manner that makes the petition easy to understand.

If one suggests that there is a problem with a script, an informed scripter can do the work more easily than an uninformed scripter.  If the problem is visual, screenshots are always recommended.  If the problem forces the game to crash, the resulting error message needs to be relayed in full.  And what may have prompted the error, the actions performed in-game, are typically quite essential.

And for those where writing code is their craft, remember for whom their code is for.  Is the user familiar with writing scripts, or is the person unaware how to code.  Will the person require additional resources or software to run your system or is it a literal plug-and-play script.  Whatever the case, whether made for a single user by request or for the masses, the script should be as easy to use as possible and with instructions as clear as water.