We need a guide to MV's base scripts!

Wavelength

MSD Strong
Global Mod
Joined
Jul 22, 2014
Messages
5,635
Reaction score
5,116
First Language
English
Primarily Uses
RMVXA
First of all, thank you to everyone for all the helpful responses! :)


To give a hopefully clearer example of why I feel there's a widespread need for not only documentation but additional information to tie all of the code together: assume a moderately competent JS programmer opens up his game's Script Base for the first time because she wants to make a couple of very simple changes to the Sell Window (perhaps a small layout adjustment to the position of each column, and an extra requirement for having an item appear on this screen).



1) First off, she has to find that window.  She can't search for "Sell Window" or even "WindowSell", although opening the correct file (rpg_windows) and searching "Sell" will eventually get her there.  Here's the code for that Window:

Code:
function Window_ShopSell() {
    this.initialize.apply(this, arguments);
}

Window_ShopSell.prototype = Object.create(Window_ItemList.prototype);
Window_ShopSell.prototype.constructor = Window_ShopSell;

Window_ShopSell.prototype.initialize = function(x, y, width, height) {
    Window_ItemList.prototype.initialize.call(this, x, y, width, height);
};

Window_ShopSell.prototype.isEnabled = function(item) {
    return item && item.price > 0;
};



Well.  That's not super helpful.


2) The first pain point is going to be the "arguments" parameter.  A good guide would explain that the screen x, screen y, window width, and window height are being passed in here from the createSellWindow method.  It might go on to explain the basics of how it gets those values, or link to the more thorough documentation on that particular method.


3) Rather than being able to see how the sellable items are processed and written to the screen, all that our neophyte MV scripter will see from this section is that the window is inheriting some of its behavior from Window_ItemList.  Okay, let's check out that window:

Code:
//-----------------------------------------------------------------------------
// Window_ItemList
//
// The window for selecting an item on the item screen.

function Window_ItemList() {
    this.initialize.apply(this, arguments);
}

Window_ItemList.prototype = Object.create(Window_Selectable.prototype);
Window_ItemList.prototype.constructor = Window_ItemList;

Window_ItemList.prototype.initialize = function(x, y, width, height) {
    Window_Selectable.prototype.initialize.call(this, x, y, width, height);
    this._category = 'none';
    this._data = [];
};

Window_ItemList.prototype.setCategory = function(category) {
    if (this._category !== category) {
        this._category = category;
        this.refresh();
        this.resetScroll();
    }
};

Window_ItemList.prototype.maxCols = function() {
    return 2;
};

Window_ItemList.prototype.spacing = function() {
    return 48;
};

Window_ItemList.prototype.maxItems = function() {
    return this._data ? this._data.length : 1;
};

Window_ItemList.prototype.item = function() {
    var index = this.index();
    return this._data && index >= 0 ? this._data[index] : null;
};

Window_ItemList.prototype.isCurrentItemEnabled = function() {
    return this.isEnabled(this.item());
};

Window_ItemList.prototype.includes = function(item) {
    switch (this._category) {
    case 'item':
        return DataManager.isItem(item) && item.itypeId === 1;
    case 'weapon':
        return DataManager.isWeapon(item);
    case 'armor':
        return DataManager.isArmor(item);
    case 'keyItem':
        return DataManager.isItem(item) && item.itypeId === 2;
    default:
        return false;
    }
};

Window_ItemList.prototype.needsNumber = function() {
    return true;
};

Window_ItemList.prototype.isEnabled = function(item) {
    return $gameParty.canUse(item);
};

Window_ItemList.prototype.makeItemList = function() {
    this._data = $gameParty.allItems().filter(function(item) {
        return this.includes(item);
    }, this);
    if (this.includes(null)) {
        this._data.push(null);
    }
};

Window_ItemList.prototype.selectLast = function() {
    var index = this._data.indexOf($gameParty.lastItem());
    this.select(index >= 0 ? index : 0);
};

Window_ItemList.prototype.drawItem = function(index) {
    var item = this._data[index];
    if (item) {
        var numberWidth = this.numberWidth();
        var rect = this.itemRect(index);
        rect.width -= this.textPadding();
        this.changePaintOpacity(this.isEnabled(item));
        this.drawItemName(item, rect.x, rect.y, rect.width - numberWidth);
        this.drawItemNumber(item, rect.x, rect.y, rect.width);
        this.changePaintOpacity(1);
    }
};

Window_ItemList.prototype.numberWidth = function() {
    return this.textWidth('000');
};

Window_ItemList.prototype.drawItemNumber = function(item, x, y, width) {
    if (this.needsNumber()) {
        this.drawText(':', x, y, width - this.textWidth('00'), 'right');
        this.drawText($gameParty.numItems(item), x, y, width, 'right');
    }
};

Window_ItemList.prototype.updateHelp = function() {
    this.setHelpWindowItem(this.item());
};

Window_ItemList.prototype.refresh = function() {
    this.makeItemList();
    this.createContents();
    this.drawAllItems();
};



This is getting intimidating...


4) Some elements on this window are pretty clear; for example it should be clear what _category is doing (though it would take a lot of additional searching to understand how and when it's changed).  But there are other methods that are going to be big obstacles for someone who's not already intimately familiar with MV's code base:

  • The window's construction inherits from Window_Selectable which in turn inherits from Window_Base.  Starting with Window_ShopSell, we're now at 4 levels of inheritance.
  • You can't search for "Column" - you'd have to find it under maxCols().  This isn't a problem if you're already here, but searching through the entire project to find "how are columns demarcated in general" will be problematic.
  • The changePaintOpacity() method is passed a boolean, and is passed an integer three lines later.  Confusing.  Wouldn't it be nice to know, at a glance, why we are calling this method and what we need to pass in?
  • The makeItemList() method is probably the most important thing our scripter needs to follow for modifying the Sell window, as it displays everything that's appropriate from the player's inventory.  It's referencing several other methods without an immediately clear reason why, and it's evaluating whether the object includes "null", in which case it will push a null value into the data list.  Not only do I think our scripter is confused, but after a bit of searching, I have no idea why it's doing this!
  • The "isCurrentItemEnabled" method isn't used directly anywhere on this window at this child level... what do we do with it?  Is it important as our scripter tries to make her change?
  • That same method references isEnabled() ... okay, that's an easy find, just a few lines down.  That method references the party's canUse() method.  The party's canUse() method, in turn, references the actor's canUse() method so our scripter would need to figure out that Actor is a grandchild of BattlerBase.  Fine, so let's check out BattlerBase's version of this method...
Game_BattlerBase.prototype.canUse = function(item) {
    if (!item) {
        return false;
    } else if (DataManager.isSkill(item)) {
        return this.meetsSkillConditions(item);
    } else if (DataManager.isItem(item)) {
        return this.meetsItemConditions(item);
    } else {
        return false;
    }
};



What a disaster.


5) Skill and Item conditions now?  How do these work?  Why is the behavior being checked from the Sell window?  There's a reason for this apparent irrationality, of course (see #6), but surely you can see how confusing this would be to a beginning scripter, no matter how well they understand the syntax and logic of JS?


6) Back to the original Window_ShopSell window, let's check out the last function.  Woops!  Looks like this child window has its own isEnabled() method, which simply checks whether there is an item and its price is greater than 0 (and our scripter might wonder whether "price" is the shop's sell price, the base price of the item from the Database, or what).  All that tracing she did to the Actor's "canUse" function and beyond was wasted time - those functions are actually for Item Lists made from Usable Item (skill/item) windows.  A short initial explanation of what the window was doing (looking for items with a base price above 0 and listing them at the screen x/y, width, and height provided) would have saved hours of confused searching and parsing of method calls.


None of this is to say that MV's code base is poorly written or constructed; I think it serves as a good illustration as to how some acquired expertise could go a really long way toward saving newer MV scripters a ton of time and frustration, and helping them make simple changes to their game without needing to become experts themselves (or make request after helpless request from scripters who have put in the time).

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.


Thanks so much for offering this, it is very kind of you!  The sticking points I've had in the past month have mostly been figuring out Battle Flow (under which conditions stages of battle transition to one another, when/how those conditions are actually checked, and what is used to actually apply a skill's effect to a battler) and Animations (how each frame is processed and the viewports, etc., needed to show an Animation's pictures onscreen, how to force an Animation to appear onscreen from any given scene).


With that being said, my point in posting this topic was not to ask for help about the things I'm personally having trouble with, but to express what I feel is a larger, community-wide need for a holistic guide to understanding everything in the script base and how each method/object relates to the others.  I agree with @DoubleX that such guides to specific elements of the game are quite helpful (a few tidbits from Hime's ATB walkthrough actually got me off the ground trying to figure out the battle system back in January), but I'm certain that an entire, consistent guide would do even more good than these disparate one-off guides about specific elements.
 

MagicMagor

Veteran
Veteran
Joined
Apr 7, 2012
Messages
201
Reaction score
38
First Language
German
As a competent programmer, although not in javascript, i just started today writing plugins and also find myself cursing the lack of documentation. Currently i'm using the split-classes download to find what i need, but it is still an error-prone time-consuming process.


So a simple thing which would make things a lot easier for me would be:

  • A list of all classes with references of super-classes (Game_Actor inherits Game_Battler f.ex.)
  • For each class a list of defined function, if possible with a brief explanation of the arguments.
  • If the classes and methods were linked, this would be perfect (basicly what the HTML-output of Javadoc in Java looks like)

This would also avoid errors due to typos when calling methods, or when trying to find a method to do something.
 

ロリ先輩

ロリだけど先輩だよ
Veteran
Joined
Mar 13, 2012
Messages
379
Reaction score
96
Primarily Uses
I don't really agree that we need a guide or indepth documentation, but what we should have is JSDoc- something that our editors/IDEs can pick up on, and if a user chooses, they can generate an API reference from JSDoc.
 

Helladen

Deviant Designer
Veteran
Joined
Jul 13, 2012
Messages
635
Reaction score
188
First Language
English
An IDE to be honest, is the best direction for a scripting type game engine. Using Sublime or some JS text editor just is not very practical, it takes many hours to learn how it all works. From scratch it is much easier using a plain text editor, but IDEs help when working with large codebases.
 

ロリ先輩

ロリだけど先輩だよ
Veteran
Joined
Mar 13, 2012
Messages
379
Reaction score
96
Primarily Uses
An IDE to be honest, is the best direction for a scripting type game engine. Using Sublime or some JS text editor just is not very practical, it takes many hours to learn how it all works. From scratch it is much easier using a plain text editor, but IDEs help when working with large codebases.
Disagree here. Recent text editors like Atom and Visual Studio Code are pretty great for JS, especially since they are very extensible, in part to NodeJS. VSC has intellisense and JSDoc support out of box now.
 
Last edited by a moderator:

Wavelength

MSD Strong
Global Mod
Joined
Jul 22, 2014
Messages
5,635
Reaction score
5,116
First Language
English
Primarily Uses
RMVXA
As one more, simpler example as to why such a guide would be helpful and even necessary for people, I recent answered a question about adding extra effects to Critical Hits in VX Ace.


This is (IMO) literally the second easiest change that can be made in the Script Editor, with changing a number being the only possible easier change.  It took me about 40 seconds to research and write the code for the answer, because I'm intimately familiar with how Ace determines and applies Crits.  If I was new but had a good guide, I could do it in 5 minutes or less.


Without a guide, though, I struggled with this kind of thing the first time I saw it, and even with some background in Ruby it would have taken me hours of guesswork, find-all, and studying of other scripts before figuring out where to apply the change (it's not under determining the crit chance where I'd initially expect it to be) and what method name to call.
 

Helladen

Deviant Designer
Veteran
Joined
Jul 13, 2012
Messages
635
Reaction score
188
First Language
English
Use WIndows and search for keywords in the plugins/JS folder. You know that Windows can search all the contents in files using the search function as can Mac. It just takes a little bit of patience.


Normally, people who can't put this much patience into something even with documentation won't get far. As nice as it would be to have documentation, expecting someone to write it for free is going to be very troublesome to expect. You also have to realize that it won't even help that much - you are better off with a full blown IDE with better intellisense. Javascript isn't too great at that. I personally prefer languages like C# and TypeScript. Javascript isn't great for building giant scripts and components. Only recently has Javascript even added Classes. But it is hell of a lot better than Ruby, that's for sure.
 
Last edited by a moderator:

Wavelength

MSD Strong
Global Mod
Joined
Jul 22, 2014
Messages
5,635
Reaction score
5,116
First Language
English
Primarily Uses
RMVXA
Well, I respectfully disagree with you, Helladen - I believe the number of "I need a script" or "How do I do this" requests we get is proof that a search function and a little bit of patience isn't enough for a lot of designers.  Figuring out the flow of the entire system is certainly not an impossible task, but as I've illustrated it's a very time-consuming and often difficult one.


(I also don't think it needs to be done "for free" - a website could be supported by ads or *******, whereas a downloadable guide could be sold as if it were a book.  I'd gladly pay $10 for a digital copy of a good guide.)
 

Helladen

Deviant Designer
Veteran
Joined
Jul 13, 2012
Messages
635
Reaction score
188
First Language
English
(I also don't think it needs to be done "for free" - a website could be supported by ads or *******, whereas a downloadable guide could be sold as if it were a book.  I'd gladly pay $10 for a digital copy of a good guide.)


I suppose. I just don't see very many people pouring money into this. It seems like only a few people. As I said, a plugin manager and a real way to edit plugins inside the software and easily see what is going on rather than using console log is much better for time spent vs. writing a guide.
 

Jonforum

Veteran
Veteran
Joined
Mar 28, 2016
Messages
1,623
Reaction score
1,440
First Language
French
Primarily Uses
RMMV
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.
yes a EXCEL COMPLET TAB please :)
 

Fronkadonk

Warper
Member
Joined
Apr 18, 2016
Messages
3
Reaction score
0
First Language
English
Primarily Uses
No, bad programmers need documentation. ;)
"Git gud" is a pretty rude response to a genuine request of this sort. Not everyone learns by doing, nor does that make them bad just because they don't do what you do specifically. Most other companies use proper documentation. I for one would greatly appreciate documentation so that I'm not relying on memory or having to make large amounts of comments myself.
 

ロリ先輩

ロリだけど先輩だよ
Veteran
Joined
Mar 13, 2012
Messages
379
Reaction score
96
Primarily Uses
"Git gud" is a pretty rude response to a genuine request of this sort. Not everyone learns by doing, nor does that make them bad just because they don't do what you do specifically. Most other companies use proper documentation. I for one would greatly appreciate documentation so that I'm not relying on memory or having to make large amounts of comments myself.
I'd actually debate that 'Bad Programmers need Documentation' is a pretty apt response, although @Helladen is coming at it from the wrong angle.


Bad programmers write bad code. Bad code needs documentation. Therefore, Bad programmers need documentation. If you look at your code in a few months, and have no idea what it does without inline comments or a guide, you're in deep water.

On the other hand, Good programmers write good code. Good code is self documenting and not unnecessarily complex. Therefore, Good programmers don't need documentation since their code already documents itself.

If the RPG Maker MV base classes are hard to understand, it's not a matter of writing documentation or guides- it's a matter of rewriting or refactoring the code to make it easier to understand. ECMAScript is by no means an esoteric language. While it has some odd points, if you're coming from more strongly OOP or static languages, it's easy enough to get into from a fresh slate.
 
Last edited by a moderator:

Dr.Yami

。◕‿◕。
Developer
Joined
Mar 5, 2012
Messages
1,003
Reaction score
757
First Language
Vietnamese
Primarily Uses
Other
IMHO, RMMV code base is not that hard to understand or hard to find what you need. The classes and methods naming is quite good and self-explaining. In real work, not so many programmers try to comment or write documents for each thing they do.


For code editing, I think Sublime, Atom and VS Code do the job perfectly. I'm currently using VS Code for Unity instead of VS and/or MonoDevelop and find no problem.
 

Helladen

Deviant Designer
Veteran
Joined
Jul 13, 2012
Messages
635
Reaction score
188
First Language
English
I was simply saying people who can't learn RPG Maker MV code are just not good enough programmers. Scripting in some engines like Game Maker is so easy that a really bad programmer can make a game. RPG Maker MV scripting is in between a good and bad programmer. The bad programmers want help, where the good ones like Yanfly and others have no trouble using it. But yes I agree good code is self documenting, but RPG Maker script is not that well documenting by itself and has a lot of hard to read classes. But I am not an expert programmer at JS and that's where I had trouble the most.


Learning through documentation is not a really good way to learn. learning through reading a book on the other hand is. Documentation is just the framework of how the code works, it doesn't teach you how to make code yourself. This is why I suggested an IDE which can actually promote learning how to use the code.
 
Last edited by a moderator:

Wavelength

MSD Strong
Global Mod
Joined
Jul 22, 2014
Messages
5,635
Reaction score
5,116
First Language
English
Primarily Uses
RMVXA
IMHO, RMMV code base is not that hard to understand or hard to find what you need. The classes and methods naming is quite good and self-explaining. In real work, not so many programmers try to comment or write documents for each thing they do.


You are not wrong; MV's base code is not that bad.  However, most programmers are not developing things where the code is open to modification by its users (who may be relatively inexperienced).  I don't feel that documentation per se is what we need, but a helpful guide to each method and each process in the game's flow that's specifically oriented to making changes as a scripter.


This kind of guide should explain where all of the data is coming from in a method/class, how it flows, how it's used, why it's done the way it it's done, and most importantly how a beginning programmer would make common changes (such as how to change a hit/crit/TP-gain formula, or how to change dimensions/style of a text field).


This kind of thing is not something that should be expected to come with MV, and I want to be really clear that this topic is not meant as a criticism of the program or its code, but rather as an identified need for an additional tool that would save people dozens of hours of searching and scrutinizing, and would lower the hurdles of access to the script base to almost zero.
 
Last edited by a moderator:

Tsukihime

Veteran
Veteran
Joined
Jun 30, 2012
Messages
8,564
Reaction score
3,848
First Language
English
You are not wrong; MV's base code is not that bad.  However, most programmers are not developing things where the code is open to modification by its users (who may be relatively inexperienced).  I don't feel that documentation per se is what we need, but a helpful guide to each method and each process in the game's flow that's specifically oriented to making changes as a scripter.


This kind of guide should explain where all of the data is coming from in a method/class, how it flows, how it's used, why it's done the way it it's done, and most importantly how a beginning programmer would make common changes (such as how to change a hit/crit/TP-gain formula, or how to change dimensions/style of a text field).


This kind of thing is not something that should be expected to come with MV, and I want to be really clear that this topic is not meant as a criticism of the program or its code, but rather as an identified need for an additional tool that would save people dozens of hours of searching and scrutinizing, and would lower the hurdles of access to the script base to almost zero.


If someone writes such a book, they can make a lot of money.


Just saying.
 

kovak

Silverguard
Veteran
Joined
Apr 3, 2016
Messages
1,263
Reaction score
1,565
First Language
PT - EN
Primarily Uses
RMMV
You are not wrong; MV's base code is not that bad.  However, most programmers are not developing things where the code is open to modification by its users (who may be relatively inexperienced).  I don't feel that documentation per se is what we need, but a helpful guide to each method and each process in the game's flow that's specifically oriented to making changes as a scripter.


This kind of guide should explain where all of the data is coming from in a method/class, how it flows, how it's used, why it's done the way it it's done, and most importantly how a beginning programmer would make common changes (such as how to change a hit/crit/TP-gain formula, or how to change dimensions/style of a text field).


This kind of thing is not something that should be expected to come with MV, and I want to be really clear that this topic is not meant as a criticism of the program or its code, but rather as an identified need for an additional tool that would save people dozens of hours of searching and scrutinizing, and would lower the hurdles of access to the script base to almost zero.
Isn't that the reason for college exist?
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Profile Posts

Our latest feature is an interview with... me?!

People4_2 (Capelet off and on) added!

Just beat the last of us 2 last night and starting jedi: fallen order right now, both use unreal engine & when I say i knew 80% of jedi's buttons right away because they were the same buttons as TLOU2 its ridiculous, even the same narrow hallway crawl and barely-made-it jump they do. Unreal Engine is just big budget RPG Maker the way they make games nearly identical at its core lol.
Can someone recommend some fun story-heavy RPGs to me? Coming up with good gameplay is a nightmare! I was thinking of making some gameplay platforming-based, but that doesn't work well in RPG form*. I also was thinking of removing battles, but that would be too much like OneShot. I don't even know how to make good puzzles!
one bad plugin combo later and one of my followers is moonwalking off the screen on his own... I didn't even more yet on the new map lol.

Forum statistics

Threads
106,035
Messages
1,018,454
Members
137,821
Latest member
Capterson
Top