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.
Victor Sant is a king of scripting. He’s created scripts for nearly every part of RPG Maker, and to handle them all, he even has what he calls a “Basic Module” to handle all of these scripts. What the Basic Module allows Victor to do is use comment calls – like a script call you might be familiar with in other scripts, but used in the comment section of all different pages. This has advantages and disadvantages. Today in this completely absurd Ru Paul’s Drag Race-themed blog post, we’ll talk about Victor’s Light Effects – later, we’ll talk about how to break it 😉
Add the basic engine; then add the light effects script below it in your script editor. And let’s have fun with this!
The Shade of It All
The best way to explain a light effect in Victor’s script is the absence of shade. So first we create a shade layer, then we add a light effect which is show us what’s underneath that shade area in a certain pattern.
We can create shade in two different places: in an event, or in a map. In the event, add a “comment” command from the event editor, and write a little something like this
Opacity can range from 0 (no t no shade) to 255 (all t all shade), depending on how dark you want your shade to be. You can also add several other lines, like red: , green:, blue: to set the color of your shade, or blend: to set a fog in your shade. So, if you want, you can combine the colors to make your shade look like a gorgeous, burnt orange sunset, rather than going for a twilight effect.
In the map, we do the same thing, it just goes in the Maps note box, like this:
P***y On Fire
The next thing we need is a light, which again can exist in an event or in a map. We can get a whole bunch of different kinds of lights, and determining which one to use can be a bit confusing.
Let’s break down the vocab:
- Actor lights are lights that are centered on an actor and follow them around. They’ll always stay centered on the actor, and it’s typically used to show the area around your main player.
- Event lights do the same thing, but follow an event
- Vehicle lights…you get the idea
- Map lights are stationary, at an x,y coordinate on the map
- Actor/Event/Vehicle lanterns are lights that change position depending on which direction the character is facing, as though holding a flash light in front of them.
To create one, we’ll use a comment call much like we did with shade, and fill in the rest there. Things like
<actor light> </actor light>
<map light> </map light>
Depending on what we’re creating, we’ll put different things in the middle.
For all of the lights, we’ll need an ID and a Name. The ID needs to be unique across all lights. This is incredibly important – Victor’s database will take that ID make it the “key” to your light, so you never want two IDs referring to the same light
The name refers to a file name in your game folder. The file needs to be in a folder called “Lights” which itself is in the “Graphics” folder. Victor has some graphics available on his download page, but you can make your own truly sickening lights if you’d like. The image should be the opposite of where you want the light to appear. So, if you want a circle of light, draw a big circle of black. This tells the script where to cut out the shade.
You can add other factors here as well, like opacity, a positional offset, or even a variation to make the light appear to flicker or pulse.
For actor, event, and vehicle lights, you also need an index: the ID of the thing the light is supposed to latch onto. For an actor light, it’s the actor id (typically you’ll want to use the ID of the character leading the party). For an event, it’s the event ID, for a vehicle it’s either 0 (for the boat), 1 (for the ship), or 2 (for the airship). We’re going for something like this:
For maps, instead of an index, you need a map x and map y to give it coordinates. Otherwise, it looks the same!
Want to get rid of a light? It’s remarkably easy.
We need that unique ID that every light gets. Just use this comment function:
<remove light: id>
And the light will disappear. If you end up with a lot of lights, make sure to manage them appropriately or you can get pretty laggy. In Vidar, I made the mistake of having a few hundred lights that the script had to keep track of. It became unbearable.
We can also change the characteristics of light and shade dynamically. For example, you can fade in or out a light with:
<light opacity id: 0, t>
Where id is that unique ID we keep talking about, 0 is the new opacity you want it to be, and t is the time to it should take to fade in frames.
We can change the tone of our shade to mimic a sunset with something like
<shade tone: r, g, b, t>
With each color getting a 0-255 value, and t again representing the length of the fade.
Stop Relying On That
Body Comment Call
This is already an immensely powerful script, but as with all of Victor’s scripts, it’s got a high learning curve. It’s also limited in a very important way: comment calls are not script calls.
There is a world of difference between how you trigger Victor’s lights than say, Galv’s Camera Control or Modern Algebra’s Quest Journal. Even though comment calls and script calls look similar, you can’t dynamically assign a variable in a comment call. For example, if we had a room with 100 torches lit by pulling a single Switch, we’d love to do something like this:
That option is totally foreclosed with Victor’s system.
Or is it? Check back next week when I discuss the secrets to building scripts that play well with Victor’s lighting script, so we can end-route his comment calls and get to some really powerful lighting functions.
And remember, if you can’t love yourself, how in the hell are you gonna make an 80-hour JRPG can I get an amen? (And thanks for indulging me this wholly ridiculous post!)