The first and most immediately obvious change to the game is the UI. It's an area I think a lot of games don't pay too close attention to, especially in the indie and hobbyist communities. Dropping by RPG maker forums, you'll often see games with incredible art, which then have completely default menus (or mostly default with just a windowskin change).
I really don't like that. If you're going to have some part of your game look polished, the entire rest of the game should follow suit, otherwise the unpolished parts really stand out. And really, in an RPG you're interacting with some kind of menu the majority of the time you're playing; out of all other kinds of games, RPGs have the largest reason to pay attention to their user interface.
With that in mind, I've gone over the entirety of the old UI and given it a new look. It's designed to be cleaner and more readable than the previous style, without sacrificing the volume of information that needs to be displayed (which is - admittedly - quite a lot; this is a tactical strategy-RPG after all).
The main menu is the only part I'm not entirely happy with right now. It looks better than before, but it's still missing something. I'll probably have another look at it down the line.
I'm fairly pleased with the rest. It's a consistent look I can maintain for pretty much any menu, it looks quite nice and you can still fit a lot of information in there, since the command menu now only takes up a small strip of space at the top (rather than nearly a third of the screen).
The summary information tabs have also been changed. Now, whenever you select a stat, all the extra information replaces the character's portrait in the middle of the screen, rather than showing up as tooltips.
This gives me a lot of extra space, which I can use for much more detailed descriptions of what each stat actually does. This is one of my favorite changes: it manages to display more information while simultaneously looking cleaner and less cluttered than before.
The game also has a proper options menu now, which fits in with the new menu style.
The main menu wasn't the only part of the UI that changed. I also went over the combat UI and gave that a new look.
Every action you perform now shows a detailed preview of the likely outcome (this used to only work for regular attacks previously, and it wasn't very detailed at all).
Whatever stats you have that can influence the outcome of the action are displayed next to your character's portrait, with the target's corresponding stat shown in that area. In this first screenshot, I'm trying to Trip an opponent, which involves hitting them, then making a Strength check, which is affected by your size relative to the opponent. So in your window you see your BAB, your size modifier and your STR modifier.
This should give you a good idea of both what your overall chance to succeed with any given action is, as well as which stats are contributing to that, and how they compare to your opponents. You can still cancel the action while looking at the preview, so it serves as a nice shortcut so you don't have to constantly keep opening up people's status windows to check what their stat values are (a problem I sometimes ran into with games like Final Fantasy Tactics).
Another part of the menu that's changed is the normal command menu in combat.
I've moved all of the combat over to an AP system. It still works exactly like D&D3.5's action system at its core, but it represents your ability to make actions in terms of points, which I think is far easier to understand than messing about trying to remember whether something is a "Full Round Action" or a "Standard Action", and how many "Actions" you have left at any given point.
I came across this system a while ago, and I think it's a pretty clever abstraction of the D&D action mechanics. Every character starts each turn with 5 AP to spend, and every action now has an AP cost associated with it, which is displayed next to it in the command menu. If you can't take an action, it shows in red, otherwise it shows up in green. And that's pretty much all there is to it. If you're interested in exactly how this translates to D&D's system, you can check out a full description of it here.
I've also added an encounter results window because, well, now that the combat is really starting to take shape and feel more like a real game, the lack of any kind of results window was starting to feel a bit awkward. So now when you finish any combat sequence, you get this:
You can view the description of any items you get in battle before leaving the window, so you don't have to remember to go back to the inventory menu every time you get a new item.
Another feature that I had been meaning to get in for a while now was combat formations. You can now place your party members anywhere on a 5x5 grid and they'll start in that formation in combat.
The direction of the formation is based on which direction your party leader is facing on the map right when combat starts, so you can run into trouble if you're attacked from behind - your entire formation will be backwards! Enemy melee units will definitely take advantage of the situation if you accidentally let your mages start out too close to them.
In addition to that, the combat engine is actually doing a little work behind the scenes to place characters correctly, so you don't have to worry too much about narrow hallways or battles with large number of enemies starting near you. If it can't place you exactly on the tile you want to start on, it's smart enough to figure out where the closest available tile is and put you there instead.
Finally, the last and largest addition to combat: Spells!
Basic spells are now completely working and fully usable in battle (by basic, I mean any spell with fairly simple and straightforward behavior: direct damage, buffs, heals, debuffs and whatnot - more complicated spells, such as Dispel and Magic Circles, still aren't quite working just yet).
I've also been working on the targeting system, which was actually quite a bit more work than anticipated. Let's take our Burning Hands spell from above as an example. If you stick to core D&D rules (which I want to as much as possible), it targets all units in a cone in front of the caster. We're working in 2D, so in this case we'll flatten that into a triangle.
So all the targeting system has to do is draw a triangle and any unit inside of it gets hit. Simple, right?
...Not really. It's actually anything but simple. How exactly do you figure out how to make a triangle out of tiles? And how do you check if there's anyone standing on it? And this is just a simple example, with the triangle facing straight up, towards the tile above the caster. What if you want to rotate it around, like this:
This is where things can get a little tricky. It took me something like 5 different tries at this before I finally got it working exactly the way I wanted it to work. If you're a bit familiar with game development, this is the point where you might say: "that's not hard, just do a triangle-point intersection with the targeting area vs. all of the units".
Well, turns out that doesn't actually work. Or rather, it doesn't work the way I want it to. While units are technically standing in the middle of a tile, they should still get hit if the cone touches any part of their tile. Unless it only scrapes the very edge of the tile (i.e. like the tiles directly to the left and right of the caster on the first screenshot), in which case they shouldn't get hit.
So, how do we get this to work? I started by making the actual triangle in real coordinates, rather than clamping it to tiles. Then, the first point is the center of the tile the caster is standing on (let's call this A). If you give the triangle an angle N and a length L, you can find the other two points with:
Bx = A + cos(N / 2) * L
By = A - sin(N / 2) * L
Cx = A + cos(-N / 2) * L
Cy = A - sin(-N / 2) * L
I'm subtracting from the Y coordinates here because Y = 0 is the top-left of the screen in RPG maker, so Y positive is down (whereas on a unit circle, Y positive is up). If you want the triangle to rotate around the caster, you'll want to add that angle of rotation (let's call it R) to the points:
Bx = A + cos(R + (N / 2)) * L
By = A - sin(R + (N / 2)) * L
Cx = A + cos(R - (N / 2)) * L
Cy = A - sin(R - (N / 2)) * L
Once you have all three points, you need to check each tile to see if it's inside the triangle. You can make a fairly trivial optimization here and, instead of checking every tile on the field, just check every tile from [xmin, ymin] to [xmax, ymax], where xmin is the smallest X value between each one of the three points A, B and C (and similarly for ymin, xmax and ymax).
This draws a rectangle that contains the triangle we're using and obviously if any unit is on a tile outside this rectangle, we already know it's also outside the triangle, so we don't even need to bother testing them. This cuts down significantly on the amount of tiles we actually need to test. Now, to figure out whether a tile is actually inside the triangle, I mixed a couple of different approaches.
First of all, I check if the point in the center of the tile is inside the triangle. If it is, then the whole tile is obviously inside the triangle, so that's all we need to check. That will catch most cases. If it's not, however, then we need to check whether it's right on top of the lines that make the triangle. This is where floating point errors can complicate things: if one of the lines that makes a side of the triangle goes roughly, but not exactly through the center of a tile (say it's slightly off-center), the previous check will return false even though the triangle is clearly dividing the tile in two.
So we need to check for that. We also need to check that the triangle isn't only touching the very corner of a tile, but no other parts of it, since that doesn't really count. After a bit of thinking about this I eventually came upon a pretty simple solution:
First, instead of treating tiles as squares, treat them as circles. That way you essentially get rid of the edges and don't have to worry about the triangle only touching the very edge of a tile. Then, just check if any one of the three sides of the triangle crosses any part of the circle that makes the tile. If it does, then the tile is considered to be inside the triangle; otherwise it's outside.
It sounds like a bit of a roundabout way of doing things, but it makes a lot more sense once you draw it out yourself. You can see how it's now pretty trivial to tell whether a tile should be hit by the triangle or not, and there's no cases of it "just barely, but not quite" touching any tiles. If it touches one of the circles at all, that tile is hit.
In case anyone's interested, this is what the code looks like:
And that's all for today! I still have a few things to work on in terms of combat (more complicated spell effects and some class abilities like Turn Undead still haven't been implemented), but it's well on it's way to being feature complete at this point.
I'd go so far as to say most of the hard work has been done on that end. Everything left is tying up loose ends (like the fact that the game does lag a bit when I highlight a really large number of tiles) and adding a bit of polish.
Stay tuned, and until next time~
