We need a guide to MV's base scripts!

[Wavelength]

In my opinion one of the hardest parts of scripting for RPG Maker isn't the syntax or the logic behind it, but rather understanding what RPG Maker's base scripts are doing and what methods it uses to produce certain behavior.  While MV's code seems fairly well-written and searchable, the sheer quantity of different methods that it bounces between, and the sparse commenting, make understanding the game's behavior a painful guess-and-check process and until we've spent hundreds of hours working around the different parts of the code base, it can be difficult to make changes that are really simple from a pure JavaScript standpoint, largely like trying to edit someone else's plugin.


I remember HBGames had a pretty good (though incomplete) walkthrough of what each page and method was doing for the RMXP base (default) scripts, but I couldn't find anything like that for Ace (where it took me months for the scripts' behavior to become second nature), nor for MV (where I'm still not even close yet).  An explanation of what each method is doing (and what other methods and properties that this method use and why), as well as a long-form walkthrough on common processes (like Skill Selection and Opening/Drawing of the Main Pause Menu), would be immensely helpful for scripters who haven't spent 300 hours searching through the code base yet but want to create stuff!


So I'm posting this in the hope that it will inspire someone who has put in that time and figured out how everything works to share that knowledge in a way that lots of people will find it.  If you make a website, it's something I would visit a ton and promote it like crazy whenever people have questions.  If you want to write a paid guide, it's something I would gladly pay $10+ for a digital copy of.  I really think it would be the single most useful resource there is for MV's other scripters.

 

[beenbaba]

I second this and agree completely with everything said by Wavelength, this would be immensely helpful. I would gladly pay for a digital copy also if this was the way the author of such guide would like to go about it

 

[Helladen]

Being a programmer means you can do this. Documentation in most engines isn't written for the entire API, you got to figure it out yourself. Consider the RPG Maker scripts a framework that you must build upon, when you dive into an engine and start making edits of it, you need to read the entire source-code before touching anything. Sure some documentation wouldn't hurt, but being a good programmer means you are capable of doing this.

 

[Accendor]

Well, that answer is not really helpful, is it?


I mean he even writes that it would be better if a single person would share their knowledge (even if he has to pay for it). I think everyone that posted in this thread until now knows that they can do it without help but that does not mean that the effort for that is feasible or that it is the best way to do it.

 

[Helladen]

Well, that answer is not really helpful, is it?


I mean he even writes that it would be better if a single person would share their knowledge (even if he has to pay for it). I think everyone that posted in this thread until now knows that they can do it without help but that does not mean that the effort for that is feasible or that it is the best way to do it.

I agree to an extent, why not pay someone to code for you though? Learning it first hand will always give you the best experience than just being told what does what. Actually working in the codebase is how you learn.

 

[Accendor]

No, it is how YOU learn and that is totally fine.


There are other learning styles and some requiere a detailed documentation. You can discuss of course if people who need this (like me) will be as good as people who did everything from scratch but the fact is:For many many plugins the information you will get from such a guide would be enough. If you encounter a problem that you can not solve you can of course still dig into the code base.


The problem for many people is: If I have to invest 100h+ hours just to understand what classes and functions do and how they interact they will simply not do it, even if they are at least mediocre developers.


You can look at me for example. I studied computer science and I can program - mediocre - in a lot of different languages, Javascript beeing one of them. However, I still chose to pay people to code for me for MV because of the "horrible" documentation (I've seen worse btw ). It is not that I do not WANT to do it myself, it is just no feasible for me when I look at it from a time/gain perspective.

 

[Helladen]

No, bad programmers need documentation.  I don't need documentation cause I can read the comments in the code, and it only takes about 30-50 hours of work to get familiar with RPG Maker MV. The old RPG Maker was much harder. Especially the way it did alias classes. I suppose I can write a guide about this soon, the knowledge just comes to me through trail and error. I just get how the code works cause I have been programming for almost 10 years now.

 

[stupid enough to like FF13]

No, bad programmers need documentation.  I don't need documentation cause I can read the comments in the code

What comments? RPG Maker MV has much less commentation than VX Ace.


Everything I know about VX Ace scripting has come from poking around at the base scripts. That involved a lot of trial and error and a lot of searching to figure out where specific things are done and what various methods actually do. Not only does MV have much less commentation than VX Ace, it's also far harder to find what does what (due to being eight JavaScript files as opposed to a list of different classes (or whatever you call them)) and the code itself is more complicated-looking than RGSS3 which can be intimidating for novices.


There's a lot of simple and easy things that can be done just with a bit of tweaking to the base scripts that you don't need others' scripts for, but for a new user, it can be difficult to figure out how to do anything with the base scripting without making the game implode.

 

[Wavelength]

Being a programmer means you can do this. Documentation in most engines isn't written for the entire API, you got to figure it out yourself. Consider the RPG Maker scripts a framework that you must build upon, when you dive into an engine and start making edits of it, you need to read the entire source-code before touching anything. Sure some documentation wouldn't hurt, but being a good programmer means you are capable of doing this.

Sure, anyone with programming knowledge can search for a keyword, find an appropriate method, look through the code, search out the entire chain of methods, read each one to understand what it's doing, and do trial-and-error Find Alls to look for the class variables that were set somewhere else by a mostly-unrelated method - and it will be a good learning experience.  That's mostly how I've done it, to this point.  But this can require hours, even to make a small change, and tends to lead to fragmented (if deep) knowledge of the system.


As RPG Maker is used largely by hobbyists or small teams who already have too many things to do and not enough time to do it, rather than by large teams of professional programmers who have the time to study the code for 200-300 hours, I really believe that such a guide would be super-helpful and probably very popular.

 

[Helladen]

I had less trouble with MV than VXAce to get my foot into the door. It was very painful to learn for the first 20 hours, then it became easy.


There's videos on YouTube already. Are they not good enough?

 

[EternalShadow]

Sorry to jump in, but saying bad programmers need docs is very presumptive and a bit ignorant - I was recently working on an unrelated thing (an offsite JS which has a config you put on your site and link to that JS) where without docs, knowing what to input into the config would've been impossible. Docs tell you if an argument requires a string or integer or whatnot. I was working with my supervisor trying to figure out why something wasn't working - turns out the integer needed  ' s around it. Without the docs, that would've been lost knowledge. It's not limited to JS either - it could be YAML or even heck, HTML with Bootstrap!


What a lot of tutorials do is tell you how to print stuff to the console or adjust tiny things or even how to download a text editor, they never really go into any detail beyond that. I have yet to find a tut that explains how to change ingame stuff, let alone prototype a method or whatnot.

 

[taarna23]

@Helladen It sounds to me like you know your way around code. Which means, to put it bluntly, the OP's suggestion is not for you.


@Wavelength The best suggestion I have is this:




I suggest skimming the code and becoming familiar with where things reside. Most things are clearly named and are very small blocks of code. Split up in the way that Zalerinian did, it becomes far easier to read and less overwhelming. I think if you look and take it in smaller doses, you'll be able to figure out at least some of what is going on.

 

[AwesomeCool]

No, bad programmers need documentation.

So people at Google, Microsoft, etc are bad programmers (the companies require tons of documentation for even the senior programmers, some require documentation that makes the code twice as long).


Why do you think that is?  Perhaps memorizing what thousands of lines of code do is inefficient and impracticable?  Or the code will have to be read and studied by others eventually and documentation is given to help these people understand the code better (and much quicker)?  Perhaps to make code more organized overall?


Or perhaps it is because all the big tech companies are filled with bad programmers?


Source: job interviews and working at what is considered one of the biggest tech companies.

 

[Helladen]

Documentation is good to have. I wasn't saying that it was a bad idea for them to add to RPG Maker MV. Commenting is typically how you are taught to program, documentation is for methods and ways about using the code.


Anyway, I can make do without documentation even when doing stuff very abstractly that requires good documentation. I can memorize an entire codebase pretty fast. It is just some people can't do this, or they just been reliant on being informed on things all the time. Companies like Google, Microsoft, etc. have documentation to help recruits understand and set standards.

 

[DoubleX]

In my opinion one of the hardest parts of scripting for RPG Maker isn't the syntax or the logic behind it, but rather understanding what RPG Maker's base scripts are doing and what methods it uses to produce certain behavior.  While MV's code seems fairly well-written and searchable, the sheer quantity of different methods that it bounces between, and the sparse commenting, make understanding the game's behavior a painful guess-and-check process and until we've spent hundreds of hours working around the different parts of the code base, it can be difficult to make changes that are really simple from a pure JavaScript standpoint, largely like trying to edit someone else's plugin.


I remember HBGames had a pretty good (though incomplete) walkthrough of what each page and method was doing for the RMXP base (default) scripts, but I couldn't find anything like that for Ace (where it took me months for the scripts' behavior to become second nature), nor for MV (where I'm still not even close yet).  An explanation of what each method is doing (and what other methods and properties that this method use and why), as well as a long-form walkthrough on common processes (like Skill Selection and Opening/Drawing of the Main Pause Menu), would be immensely helpful for scripters who haven't spent 300 hours searching through the code base yet but want to create stuff!


So I'm posting this in the hope that it will inspire someone who has put in that time and figured out how everything works to share that knowledge in a way that lots of people will find it.  If you make a website, it's something I would visit a ton and promote it like crazy whenever people have questions.  If you want to write a paid guide, it's something I would gladly pay $10+ for a digital copy of.  I really think it would be the single most useful resource there is for MV's other scripters.

As far as I know, there are quite some existing tutorials, like those written by Tsukihime


I've also opened 2 topics about the default RMMV battle flow so far, and I hope they might be the kinds of tutorials you're looking for:


Basic knowledge to the default RMMV battle flow implementations


Solid understanding to the default RMMV battle flow implementations(updated once per week)


Later I might open an even more advanced topic(thorough comprehension), when I've finished the solid understanding one and I feel I'll be up to the tasks

 

[AwesomeCool]

@Helladen - That sounds a lot better and more clear then what you were saying before.


I agree that comments are a better way to understand what is going on in code, but I would argue that the comments in MV's code are very sub-par (some basically repeat the obvious point of the class and that is it for the entire class).


This leaves the only real way to understand what is going on to looking at a part of the code you don't understand and back tracing to a point where you do understand and then working your way through it (one line at a time).


This is very time consuming and very inefficient to going through.


I personally want MV to get much more descriptive comments and some good documentation.

 

[Helladen]

Yeah I wasn't saying not to write documentation cause some people can program without it. I was just saying that people should try to work without it as much as possible, it makes you reliant on it to be able to achieve what you want to do. Since you know, programmers in the old days didn't even have a text editor, they had to write everything on a piece of paper to keep track of what was going on.

 

[Lemur]

As a professional programmer, the myth that you need to suffer through crap documentation is absolutely toxic. Take a look at Rails, EmberJS, and Spark. They have fantastic documentation, resources, comments, and community help. Go to the polar opposite and you have most apache products.


Poor documentation is entirely the fault of bad programmers. I'm not going to suffer through "learning" a code base for every single project that decided to skimp on docs.


That being said, and from my brief read through the MV code, it's already poorly structured in massive files without much of a coherent division. A comment does not serve as proper delimitation between classes being worked on. That's what folders and files are for, as well as good documentation to explain it.


Style wise, they're incapable of choosing between camelCase, snake_case, or Some_Combination_of_Both.


Really though, this is what tests are for as well. I'd be tempted to restructure a lot of it myself and build in requireJS to properly modularize it for testing, but I doubt that any of it would be merged in either, making it slightly pointless.

 

[Jeremy Cannady]

What part in particular are you wanting a guide on?
There is lots of code but if you narrow it down I could probably help out.

 

[Tsukihime]

It depends on how detailed you need the reference to be.


If I were to summarize MV's codebase, I would break it down as


Managers


Data objects


Game objects


Sprites


Scenes


Windows


For me, most of the methods contained in each class is not too important, because they do pretty much what I expect them to do.


If I were to design the classes, it would likely be very similar.


Most of RM's code is tied to what you see in the front-end. You have your database, which contains things like


Actors


Classes


Skills


Items


Weapons


Armors


Enemies


Troops


Animations


Tilesets


Terms


System


and so on.


Game_Battler, for example, represent your actors and enemies in battle.


There's some inheritance tree where you have Game_Battler, Game_Actor, and Game_Enemy.



Battlers perform actions, which are represented as Game_Action


Each action produces a result, which is represented as Game_ActionResult


Each battler has a Sprite_Battler that is used to draw them during battle.


Then you have Sprite_Actor and Sprite_Enemy for specific methods.


Most of the classes, to me, are pretty intuitive, when I go down the list.


Aside from BattleManager, everything is pretty decoupled from one another.