If you want to get the most out of RPG Maker, learn Ruby. In the meantime, lots of talented scripters have done the work for you. Every Friday, The Iron Shoe features a fun script and goes into detail about how to use it. It also covers a little bit of Ruby each time so you can make even more out of the script.
Today I’m talking about Yanfly’s Save Engine! Rather than go into how to use the script this time (because Yanfly is notoriously a clean coder, strong commenter, and all-around genius when it comes to scripting), I want to talk about breaking it. A few weeks ago I posted my modified save menu, let’s dig into how I did that.
Designing the Save Screen
The first thing we need to do is figure out what, exactly, we want on our save screen. After really talking out what matters in Vidar, and what we like to see on save screens in general, a few notes came to mind:
- Save Screens show us the progress we’ve made in a particular file. Often times we track that with different variables like gold, playtime, character levels, but the goal is to give a graphic way of saying “this is where you are in the game.”
- Vidar‘s progression is charted by day, and we already have a variable that represents what day it is, so let’s draw that
- The other thing which distinguishes each save file is which NPCs have died. The player, in fact, never changes. So while we normally draw the player and display his level, since none of that applies, let’s look at the NPCs instead.
Clearing Out Unnecessary Draws
Yanfly’s engine does way more than I need it to do. He creates a function called “draw_save_contents” that handles all of these. It looks something like this:
You can tell just from looking at these things what they do, and can comment out the ones you don’t want accordingly. I don’t want playtime, total saves, gold, or location, so I put a “#” in front of each of those lines. Save Columns 1 and 2 reflect the fact that Yanfly’s engine can display any variable you want it to. I only need one column with one variable – “day” – so I commented out column 2 as well.
Now we’ve cleared the screen of any information we don’t care to display.
Drawing The Actors
This one gets more tricky. Right now, the drawing characters asks who is in your “battle party” – typically, the first four members of your party – and draws them with a lot of information. Find the part that looks like this:
Again, there is a lot of unnecessary information here. Specifically, my NPCs don’t have levels. So let’s get rid of all that stuff.
Now the big change. We aren’t drawing party members, we’re drawing a select number of NPCs – in my case, they’re all actors. Specifically, they’re actors 8 – 31. So instead of a for each loop, I can actually just call draw 24 times. Ruby has a great “.times” loops, so I’ll use that. The next thing is, we have to do a bit of math that Yanfly never ran into. Because he was only drawing, at max, four characters, he never had to worry about rows.
I have 24 NPCs. You bet your ass I have to do this in rows.
So, “dx” – the x spacing between each character – is multiplied by (i % 5). This is “modulo” and it’s a really handy way of doing columns or groups of things. It asks for the remainder of i divided by 5. So, for actor 0, it’s 0. For actor 1, it’s 1. For actor 2, it’s 2….for actor 5, it’s 0. For actor 6, it’s 1. You can see how this gets us a loop that goes 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, etc., we can multiply this number by our x-spacing to figure out exactly where the NPC should be, horizontally speaking.
For “dy,” we use another neat Ruby trick. When you divide a number by another number, you get an integer result, not a fraction. 1 divided by 5 is 0. 7 divided by 5 is 1. So dividing by 5, we’ll know exactly which row the NPC falls in, and we can multiply that by dy to get the height.
It then comes down to playing with some spacing, which you can do both in this function, and the original one which passes in certain arguments. All in all, it looks like this.
Note that nothing in the save engine modification changes the actor’s graphic to black and white if they are dead. This is actually handled in the NPC death function, which, when it kills an NPC, actually replaces the actor’s graphic. Since the save engine is just drawing whatever sprite is assigned to that actor, you can dynamically change the graphic as you need to.
Adding the Day
The finishing touch is scrolling to the top and telling Column 1 to display my “day” variable.
And that’s it! The final product, once I tweaked all of the positions, looks like this: