I started looking into RPG Maker MV to update some of my VX Ace scripting panels and posts, and… it’s different. If you’ve read some of those posts, here’s a few things that might help with the transition.
For example, if you build your project for web, the index.html file is literally just a list of the code files in your project:
This seems like a smart move, because it makes it easier to support multiple platforms. There’s at least one way to run HTML5 on every platform.
It also means you have access to all of the code in your project. For someone who’s comfortable digging into the inner workings of the engine, that’s huge. It allows for a lot of flexibility, but it means you also have to be careful. (Regular backups or source control are, again, crucial.)
… which is a double-edged sword
VX Ace’s Ruby code seemed to use fairly standard object-oriented programming practices. This made it easier to explain–classes are templates for things that can exist, methods are actions those things can take, properties define the details of those things, etc.
(To make things more confusing, MV tends to throw multiple classes into the same file, whereas VX Ace’s script editor had a well-organized list of classes.)
But it’s not actually bad. You can do some powerful things if you know what you’re doing. It’s probably not where you want to start programming, though.
Built for real development tools
One of the most frustrating things about working with VX Ace as a developer is everything is stuck in a binary file. Code was only editable through the RPG Maker application. Collaborating through source control was a pain, because there was simply no way to merge changes.
Since you can build for the browser, you can also debug your code using your browser’s built-in developer tools. This is good, because the playtesting mode error display doesn’t seem to be as robust as it is in VX Ace. You’ll get the exception type and error message, but not the filename and line number.
While you can find a number of “plugins” for VX Ace out there on the internet, they often just involve dropping code into a blank page of the script editor. That is, you structured them the same way you would any other additional code.
Plugins seem like a good way to structure your code.
I’ve already worked through my previous “gold window” example in MV, and I found it a little trickier. (Again, playtesting mode doesn’t give you as much information about unhandled errors.)
The good news is, I could build the same thing in the plugin system in only a few lines of code, simply by replacing a method. To me, that’s a win, but I’m not sure what the newbie-friendly blog post for MV scripting looks like.
I still plan on updating my panels (post-AWA) for RPG Maker MV, but I’ll have to think about what that looks like.