WIndowskins affect our games’ messages and menus, so let’s take some time today to figure out what each piece of a windowskin does and how we can edit them!
Our windowskin lives in our game’s system folder with the name ‘Window’. MZ’s default windowskin is simple so that it can fit into all sorts of games, but if you want to have a more fantasy-inspired one then you’ll need to edit it yourself.
Over on the forum we can find the RPG Maker MV/MZ Templates and Guideline and find a template for the window, which breaks it down into separate parts that make it easier for us to make our own:
But it doesn’t go into details on how each part works, so let’s take a look at each section and see how they affect our messages and menus. Keep in mind that this is how the windowskin works by default and doesn’t include any changes made by plugins.
I’m sure you’ve seen the default windowskin looks in-game, but since we’ll be making changes here and there in this tutorial to show how they work, let’s remind ourselves how a message and menu look with the default windowskin:
The first part of the windowskin we’ll look at is the background, the 96x96 pixel upper left square.
This part is stretched to fit the window, so simple backgrounds such as gradients or solid colors are best. If you place a fancy pattern there, it will be stretched or squashed to fit the window and could ruin the look you were going for.
If we remove it from our window skin then our windows end up being almost totally clear, making it a lot harder to read any text there. So having a background is an important piece of a windowskin.
Beyond editing the window skin itself, we can also make some adjustments in MZ’s database. In the System 1 tab we can tweak the window’s background color:
And in the System 2 tab we can adjust the Window Opacity:
That Window Opacity option gives us a lot of control over the window background. If we edit our windowskin to have an opaque background and change the Window Opacity to its max (255), then our windows will all be solid.
In-game, we’ll see just how that changes our window background. Nothing can be seen behind our test message, which is great if we want to make it easier for our players to focus on the dialogue and not get distracted by what’s happening behind it.
Next, let’s check out the background pattern in the 96x96 pixel lower left square of our windowskin. It’s hard to see, but MZ’s default pattern is slightly transparent white diagonal lines.
This pattern is tiled on top of the window background to add some extra texture to the windows. Because the pattern is repeated over and over to fill the window, it’s best if the pattern doesn’t clash with the text or make it hard to read (while a phrase from the game could look cool as a window pattern, having text behind the game’s actual text can make it harder for players to read dialogue).
If we remove the default pattern from the windowskin, we are left with windows that don’t seem very different at first glance.
Now, what if we changed the pattern to be something more obvious, like semi-transparent black diamonds?
In-game the change is clear right away.
With our windows’ backgrounds sorted, we can move on to the 96x96 square in the upper right: the border. The border is an interesting piece of the windowskin, in that it doesn’t actually include the 48x48 pixel square in the center. Instead, the border is controlled by the outer edge of that section.
How the border expands is also unique. The border’s sides stretch to fit each window, like our background, but each corner remains the same size to make sure that the window’s background corners don’t peek awkwardly from behind the border. If we take some time to experiment with the border, we’ll find that the center 50 pixels of each side are what are stretched, leaving us with 23x23 squares in each corner that will stay the same.
One thing we do need to keep in mind when making wider borders is that if we make them too wide it’s possible to have them appear behind text and menu options, so it’s best to playtest often to see how it looks in-game and use that to decide if you want the border to be wider or if it looks better narrower.
Removing the border leaves us with some boxy windows, which could work for certain games. We can also see that our window backgrounds don’t extend as far as our borders, which gives us about 4 pixels on each side where the background wouldn’t poke out beyond the border.
Now that we have a better understanding of the border, we can make our own with 16x16 pixel squares in each corner and simple sides.
And in-game our border stretches properly, leaving us with clean lines the whole way around each window.
Towards the center of our windowskin is our 48x48 pixel selection cursor. This is what is used when selecting any options in a menu or choice list, so having something obvious is important.
If we remove the cursor from the windowskin, then we have no way to know what we’re going to select in the menu!
The cursor expands in a similar fashion to our border, though in this case the corners only have a 3x3 pixel square that won’t stretch. We can make a simple one with small squares in the corners and plain white lines making up the sides. Along with the opaque edges, let’s fill the center of the cursor with a transparent white.
With it ready, we can open our menu and see how it looks. While having the cursor completely fill up the window skin isn’t necessary for it to work, it’s good to make sure that the player’s selection is obvious and a good cursor can help.
The 48x48 pixel square in the center of our border section is where we can find the menu arrows.
These arrows don’t appear as often as the window border or cursor, but when they do appear it’s to help our players know that there are more things to scroll through in a menu. For example, if you have tons of items, the up and down arrows will show up so that our players know there’s more to see.
If we remove the menu arrows, then it makes it harder for our players to know if they need to keep scrolling to see all of their items or if they’ve reached the end. So while at first these arrows don’t seem necessary, having them is important in larger games!
Using the default arrows as a guideline for these is the easiest way to make new ones, so let’s do that and replace them with some black-outlined arrows.
In our jam-packed items menu, we can see our menu arrows appear properly.
To the right of our selection cursor is the 48x48 square that makes up our message pause cursor. The pause cursor is actually made up of 4 24x24 squares that animate to create the little symbol that appears when our message is finished displaying.
The pause cursor animates left to right and top to bottom, so the upper left square is first and the lower right is the last frame. Once the animation hits that last frame, it starts again from the first one.
Removing the pause cursor makes it a lot more difficult to judge if the message is finished or not, which can get annoying after a while. So make sure that there’s a visible pause cursor.
As long as we keep each frame sized properly, we can make anything animate as the pause cursor. For this example, let’s shrink the ‘silence’ balloon and use 4 of them to create an ellipsis cursor.
When we play a message in the game, our pause cursor plays its ellipsis animation and our players will be sure to realize it’s time to move the dialogue forward.
Last, but certainly not least, are the text colors in the lower right of the windowskin. This section is made up of 32 12x12 squares of different colors.
Each square is a possible text color option in message boxes, as well as affecting the color options for things like HP, MP, and system colors in menus. For the exact colors used in menus you can search the rmmz_managers file (found in your project’s js folder) for the term ‘ ColorManager.textColor ‘, and read below that to find which color is tied to each part. If you don’t need to know the exact colors, then just be aware that the lower 16 colors mostly make up those menu colors.
Changing the color in a message is done with \c[N], where N is replaced with the number tied to each color (from 0 to 31). Now, knowing which number is tied to which color can be tough if you don’t memorize them or make a cheat sheet for them. Luckily, in MZ selecting a different color in a message is easy if you right-click and use the ‘insert color index’ option, which brings up a window with each color visible.
Were we to erase all the text colors, our messages and menus will be filled with just black text.
While we could edit the colors in our windowskin, I’m pretty sure we understand how replacing a color would change how that color appears in-game.
Now that we’ve talked about each section, we can take all the edits we’ve made and put them into a single windowskin to see how they all work together.
Our new windowskin is definitely unique, but since each part was done separately it’s quite clear that they don’t all work together to make a cohesive design. When working on your own windowskins, make sure to playtest and see how each part works when next to the other parts.
And with all that covered, you should be ready to edit your own windowskins! What changes will you make to your windowskin to help it better fit your game’s aesthetic?
Have you ever made or seen a “I need this thing, otherwise I cannot continue working on my game!” type of request? While I understand that some elements can be crucial to have, there is no reason to have the lack of a resource restrain you from working on your project. In fact, the lack should not affect you at all - for the moment.