Proper Script Placement and Usage for RGSS 1 through 3 - Printable Version+- Save-Point (https://www.save-point.org)
+-- Forum: Games Development (https://www.save-point.org/forum-4.html)
+--- Forum: Tutorials (https://www.save-point.org/forum-19.html)
+--- Thread:
Proper Script Placement and Usage for RGSS 1 through 3 (/thread-7476.html)Proper Script Placement and Usage for RGSS 1 through 3 - kyonides - 05-12-2019
Proper Script Placement for Custom Scripts
In this occasion I want to make a few recommendations concerning where to paste your beloved custom scripts in the maker's script editor. I hope they will prevent you from making those terrible mistakes that usually make your game crash like a car driven by a drunkard.
Rule 1: Scripts that rewrite an already existing method or even a whole class, need to be placed BEFORE all other scripts that aliased those methods.
Rule 2: Do exactly the opposite for any scripts that include aliased methods.
Rule 3: Parent classes should always be placed before their child classes either on a previous section or at the top of the same page where their child classes are currently located. It's excessively important for inheritance!!
Rule 4: Respect the script pack order at all costs! Scripters should not be blamed for people that misplace their scripts even if the scripters have provided a demo showing you how to place them in your script editor!
Friendly Suggestion 1: Never edit any default script right in their original section of the script editor's list. Use a new section that you can remove at any given time if you messed up with your game system and it is no longer working properly.
RE: Proper Script Placement and Usage for RGSS 1 through 3 - kyonides - 08-25-2019
Proper Script Usage for Custom Scripts
Never try to edit a script that doesn't offer you some getter or setter method or an extra variable or array or hash or Constant.
Learn some basic scripting first!
Learn some basic scripting first!Many scripters get bored of listening to lazy game developers that pretend to be top notch but know nothing about coding and still state stuff like a script is crappy. Most of the time its the users' fault!
They don't know any RGSS or Ruby or JS or anything and they change complex stuff and later complain about what they have broken. 
Don't use Constants as simple variables!
They are named Constants because their contents should remain the same!!
So if it's a boolean or a number or an array or a hash, leave it as it is! Only change them if the scripter told you what values were valid there! 
Scripts Are No Miracle Workers!
They are just some tools to let you extend a game engine's list of available features. Scripts have limitations like practically having no access to low level functions unless you get libraries like the incompatible and forgotten and deprecated Win32API. Of course modern replacements of your game engine might let you use a lot more features by default or by loading custom rubygems available online.
Don't forget to install them on your system to test the rubygems! 
High Level Programming Languages Usually Are Not as Fast as Low Level Ones! 
Even so languages like Ruby (version 2.x and above) really care about speed and get improved every single time they find a way to do so. Yeah, that's the price you pay for making a language as human readable as possible.
Still, Python, Ruby and others let you compile your code to bytecode to make them run in no time. They can also be compiled if needed. Compiling stuff makes it a closed project for average users like you. High level languages actually let you extend a language at some specific point or at any time in Ruby's case! You're free to create as many classes and modules are you wish.Do Not Rely on Global $Variables!
Most of the time newbies come up with their so called amazing scripts but forget one thing... They create too many $variables!!
That's a hard blow for your game! You could end up cutting off its head... if it ever had any. They consume most resources so spare them as much as possible. Only depend on them if you excessively need dinamic loading or stuff updating. In my experience changing stuff like $game_temp might end up getting quite ugly in the RM series. Still, you could load stuff like items list to a module's variable if you wanted.X Y Coordinates
Thank Descartes for his contribution since he let us use them in silly stuff like videogames.
In the RM series you set a sprite or window or event at some coordinate by setting their x and y cartesian coordinate system. In the original version and even in OpenGL rendering IIRC, the X 0 and Y 0 position is located at the lower left corner of your paper or monitor or phone screen. Most applications place it at the upper left corner and the RM series are part of this trend.In RGSS every single tile has a fixed width of 32 pixels and the same is valid for its height. If talking about maps every single position should be multiplied by 32 to let you know it's real position on the map. On scenes that isn't necessary at all.
Curiously there are times when sprites or windows might get placed on screen even if they are supposed to be located outside the current view (called the camera view IIRC). I'm not sure if that's a feature or a bug. Usually windows ask you to pass one or more arguments concerning its actual coordinates or its width and height. Window_Command only asks you to send it some width and array of strings to be used as labels for every single option you'd ever need. Sprites don't necessarily need that, but you can pass a custom Viewport or later on call their setter methods to define its x and y coordinates. Their default values are well known, they're 0 and 0.
Passing Strings as Arguments
If you want to pass anything that is not a string to let the RM print it, use the .to_s method by appending it there. There's also a feature called interpolation and printf but they might be kind of advanced for most people. The only valid exceptions to this rules are puts and print, they might get ANY value and they'll try to print it at all costs.
Fear the Devious Loops!
Never place methods or complicated stuff there, especially if you don't need to keep updating them every single frame! Every single unnecessary stuff located there will slow down your script!
So don't even dare to place a second or third loop there ever!! Your Main Task
All scene scripts need a main method. Either you define it in your class or its parent class but you can never ever skip it!
You won't see anything related to it if you never defined it! Actually your game should crash immediately! Never include a main method in Sprites or Windows!!