New Script Slot vs Modifying Original Classes

[Shaz]

This question is for scripters, not for people using someone else's scripts in their project.


When you write scripts for your OWN projects (not to share) and you are adding to or modifying existing methods, do you put the script into its own Materials slot, or do you change the original code? Why?

I tend to like having things all together, and I'm wondering if my reasons for doing this are really worth it. So I thought it'd be interesting to hear from others, as well as get a list of the pros and cons of each method.


Modifying Original Class
Pros

• Everything for a class/method is in a single place.  No searching through multiple scripts to find everything that happens within a method
• No need to alias or overwrite classes.  I haven't tested (but I should), but I suspect every time you alias a method, it adds a miniscule amount to the processing time whenever that method is called, for the extra step of jumping to the aliased method (it would be just a tiny amount, but aliasing Game_CharacterBase.update 3 times in 3 different scripts, when you have 100 events, means looking up an aliased method 300 times per frame) - I would be happy for someone to tell me that this doesn't happen, that the process of compressing a game merges all the method aliases into a single call
• It just has a perception of being neater and more organized.  My opinion only, and whether or not it makes a difference in any other area, being well organized is important to me

Cons

• Makes it hard to share scripts
• It's a bit risky when making new scripts - editing the original methods doesn't give you a "clean slate" to go back to if something goes wrong, so you have to remember what you changed, and where you changed it
• Hard to copy individual scripts from one project to another

Mods in New Script Slot
Pros

• Easy to share scripts
• Easy to keep new mods contained - if something goes wrong, you know exactly which script slot contains the offending code
• Still organized, but in terms of script purpose rather than classes

Cons

• If you want to change something, your class/method could be in one of several script slots - lots of searching, checking to make sure you're changing it in the right place
• Risk of recursion, if you unknowingly use the same alias on the same method in more than one location
• Extra concern of getting the location of the new script correct - does it have to be above or below other scripts, does the alias have to be called before or after your new processing, are you actually aliasing or overwriting the original method?

What else can you add?

 

[Zalerinian]

i prefer to have everything in a separate slot. In the event I need to test an incompatibility, I want to revert the changes entirely, or I just want to check something in the original, it's much easier to go back. If you're having trouble finding things, they don't have it noted anywhere (that I can seem to find), but ctrl + shift + f will search ALL your scripts for what you're looking for, rather than just the current one, and give the matches to you in a table:

Spoiler

So that could make it easier for you to find things if you know what you're looking for. Good luck with more advice!

 

[Engr. Adiktuzmiko]

I use the new script slot method nowadays... before this, I was using the edit the original method, but it's a pain when I get errors and need to bring back the original code...

Right now, for windows I do it by creating a new class that extends the window class that have the methods that I want to override/alias... then for the scene classes, I overwrite the part where they create the windows to use the new class...

IMO, doing it this way makes it easier to counter the cons that you posted because each class will most probably be in it's own script, so it's easy to find and (IMO) also reduces risk of incompatibilities since the changes are only made to the new class, and only the scene where the class is used have aliased methods that might still be called by other scripts...

 

[Shaz]

ctrl + shift + f will search ALL your scripts for what you're looking for, rather than just the current one, and give the matches to you in a table:

I know about this, but if you have 6 scripts that all alias the same method, you've still got to look at each one of those scripts individually to see what they do.

Right now, for windows I do it by creating a new class that extends the window class that have the methods that I want to override/alias... then for the scene classes, I overwrite the part where they create the windows to use the new class...

Doesn't that mean that you then end up with scripts for windows that aren't used at all? Don't you think that's messy and confusing?

 

[Engr. Adiktuzmiko]

Confusing, well not really since this is only for my own use...

Though yeah, it means that I have scripts that aren't even run... but they don't take much file size do they?

Plus I only do that for window classes used by specific scenes... for the Game_ classes, I still do it the normal (mod in new script) way...

 

[Tsukihime]

I write most of my code in RM editor and don't use version control, so if something breaks, I'm probably not going to know what change broke it.


Much easier to just comment out a script or two to determine where the problem is, and then narrow down the issue from there, since I know the base scripts work. Even if 5 scripts alias the same method, it is a lot easier to comment out those 5 scripts (just do tests and you should have found your issue) than having to figure out which of the base classes is messing things up.

 

[Andar]

One additional contra to editing the original method is that you have to remember where you edited them.

That might not sound like much of a problem at first, but what if you work on the game for several months with a lot of changes, then want to add someone else's script only to find out that it's incompatible with your modifications to the originals?

If all modifications were added scripts, you can comment them out until you found the problematic one. If it's incompatible because of one of your changes in the original scripts, that is no longer possible and you have to hunt down every change you made in the default classes to find the problematic one.

 

[Fomar0153]

Depends on the project but I certainly have a few where I just edit the default scripts, it's just quicker, especially when writing battle systems.

 

[Mithran]

There is not really much reason not to use a new page. Even if you are copying methods from the base scripts and editing them slightly, at least you have all the changes separate that can easily be reverted. If you are writing scripts for yourself and only yourself, you don't really need to ever alias a method and if need be you can just write the code in your 'working copy'. Or you can reopen the class later and alias some methods on yet another page and make changes there. If you are using new slots and aliasing to add some stuff I've never had any trouble searching through methods that I've written myself, recursion is easily fixed and pretty easy to identify if it even becomes an issue. Aliased method calls do need to be processed at run time, but the amount of time is comparatively tiny. If you reopen the class and only use rewrites or edits, that eliminates your entire 'cons' list and you can continue keeping one class per page (with the added bonus of being able to comment out a method or the entire page of your script and have the old one take back over if something goes wrong).


The real question is whether you want to organize your custom scripts by function (one page per one effect/group of effects) or class (one page per one class reopen). I have done both, depending on the project, but I rarely just edit the base scripts unless it is a single line modification or I am trying to do something very quickly. It all depends on what you are trying to accomplish. I tend to find that grouping by class can make writing things faster if you already have everything mapped out, and can be easier to debug if you are familiar with it. But depending on how much effort you give into preserving the original structure, grouping by effect also means you can pull out pieces and put them in other projects or share them (even if you weren't planning to originally). Granted, for future projects you can still modify the complete working game engine, well, exactly like you did to make the engine in the first place, but you wouldn't be able to share any part of it as all of it is required for it to work.


As for the other question, looking up your aliased method in a method does take some time, about the same as it takes to look up any method. It is, however, very tiny. Based on bench tests I have done on my very old computer (win xp 2.8 ghz with 2 gb ram), and the scenario you have stated above (100 events, 3 additional method calls per path that wouldn't be there if you consolidated methods), I've calculated that approximately 0.2-0.5% of the time given between each Graphics.update would be devoted to just those alias calls. However, you would also have to consider that those same amount of events on any given map would also cause me an 80% drop in framerate with vanilla scripts. So even given 10-20 times that many extra alias method calls on the same path, consolidating the code into a single method would show no noticeable benefit (I'd be 500% overloaded instead of 505% overloaded). If you are redefining, keeping the dead code around in the base classes will also cost you almost nothing (for me, about 0.01 seconds of extra startup time per thousand lines of 'garbage code').