All of the UI

It's been quite a while since I last made an update, but I've been steadily working on the game since then and I think it's about time I get around to making another update. So here it is!

Some of this is going to echo a bit of the last post. Probably the biggest changes since I've last written about the game were, once again, in UI. But there's a big reason for that! Sometime late last year I found out that the good folks over at RPG Maker Web finally figured out a way around RPG Maker's increasingly annoying resolution limit. Here's the thread, for future reference. I encourage everyone using RM to take a look at it.

It had a few fits and starts and required a lot of additional modifications as RM wasn't really made to support large resolutions. But once the initial hurdle of actually bumping the screen size up itself was overcome, everything else necessary to get it working correctly was easy by comparison, and there was no shortage of programmers interested in helping out - a lot of people have wanted to see a script like this come into being for a long time now.

After a few months and the work of several awesome people in the community, I'd say the script is mostly done. I've added in my own contribution to it, and I've been using the script for about two months now, and I can say that it definitely works.

The problem is, of course, once the actual resolution of the game is changed, the whole game has to change to suit it. Primarily, that means re-sizing all of the UI. The amount of work was further compounded by the fact that I took this chance to re-visit my choice of control scheme (previously console-style gamepad controls), and I decided that the game would play much better if it was more of a mouse-and-keyboard, PC-style game. So I essentially had to rewrite every piece of UI I had ever done for this game.

That took me a few months to do, but I did eventually finish it. It currently looks like this:

It's maybe not as artistically pretty as the previous UI (though I'm the middle of getting some help with that part of it too - more on that later), but it's certainly much easier to understand and navigate, and it allows me to display much more information in one screen without making it seem too cluttered.

It really matters to me that the game's (admittedly fairly complex) mechanics are approachable to people who have never heard of D&D before, so I'm trying to take as much advantage of the new control scheme as possible to improve on how the game conveys information. One of the first things I invested into doing once I had the player using a mouse is add tooltips.

I wrote them in a fairly generic way, specifically with the intention of being able to attach one to pretty much anything. So now, the vast majority of things in the game have the ability of displaying additional information when you mouse over them - from arbitrary regions in the menu, to enemies, items, NPCs and interact-able objects in the environment:

As you can tell from the last screenshot, the UI is not the only thing that's changed significantly. I've finally updated the game's graphics to a style that's much closer to what I originally intended to have.

The actual combat mechanics haven't changed too much, other than being cleaned up and polished a bit more. The biggest difference is in the presentation.

I did implement quite a few things that I had been holding out on before, however. One of them is Cleric domains:

I modified them a bit, compared to how they normally work in D&D. Usually they provide a handful of spells, and maybe some kind of special domain power. They're more of a small add-on to a Cleric, than anything else. I wanted to make them more meaningful, so I flipped things around a bit.

Now, Clerics have a fairly small initial spell list. To expand that list, you pick domains. In exchange for the much more restricted list of native spells, you get a lot more from domains than you usually would. Each domain adds exactly one spell to your spell list for each spell level, which effectively gives you 9 new spells. You also get more of them - two initially, then another one every 5 levels. 

Gone also are domain spell slots. Spells earned through domains behave just like any other spell you have, with no special restrictions or limitations. This should make building a Cleric a lot more interesting than before: which domains you pick will now dramatically change what your Cleric can actually do.

This ties into another area that's had a major change: spell-casting in general. So I mentioned that domain slots are gone - well, they're not the only ones. I've done away with the entire concept of spell slots. Honestly, I think the Vancian casting system has sort of outlived its purpose, and it seems many people agree.

I ran across this post on giantitp a while ago, which proposed the idea of replacing regular, slot-based D&D casting with a variant based on how Psionics works. It essentially turns it into a more standard RPG mana-based system, while still adapting things here and there to work with all of the other D&D rules. You can view a (very) detailed description of it here.

I already had completely implemented the standard D&D casting system at this point, so I went ahead and rewrote so it functions mostly like that variant system above. You probably already noticed this if you were looking at the screenshots above closely enough: the blue bar in the top of the status window is displaying the character's SP - or Spell Points.

I say it's mostly like that variant because I tweaked a bunch of things myself that I didn't quite like in the document above, like the exact amount of Spell Points each class gets at each level. In any case, I like the overall result: it's much easier to understand than traditional D&D casting (seriously, who really wants to spend 15 minutes preparing spells before heading out to a dungeon?), while also being easier to implement and balance.

 That's all for this update. I don't want to make it too long, and it's getting a bit late. I'll try to go back to making more frequent updates as the game gets closer to having a real demo out, and I'll definitely be talking about that here once it happens.

Until then!

A HUD is fine too

Mid-march is rather late for the first update of the year, but better late than never! And while my blog updates have slowed down quite a bit, progress on the game hasn't at all.

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.

It sounds a bit involved when I actually have to describe it, but if you draw it out on a piece of paper, that's the only way that really makes sense. If you do it any differently, it looks like either too many or too few tiles are getting 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~

The Robe and the Wizard Hat

It's been a while since the last update, and quite a lot of things happened, so this will be another rather long update. I really should do these more often so they don't end up so huge.

First up is feats. The vast majority of them are done. Out of the 170ish (give or take a few) feats I entered in the game's database when I started working on the feat-selection board earlier in June, all but 9 of them are completely implemented.

I've also added something which slipped my mind before - characters all had races, but I had forgotten to address the issue of racial types and subtypes. Ogres, Tolls and Hill Giants are different races, but they all belong to the Giant type, for example. So I went ahead and implemented that, which also allowed me to complete all of the racial feats, such as the Dwarven Defensive Training feat, and the background feats I've mentioned in earlier updates, which allow you to assign a unique bonus to each character on character creation.

Additionally, all core combat actions (e.g. Bull Rush, Fight Defensively, etc.) are now available, including ones based on class-specific feats:

This means that all melee-centric classes, like Fighter, Barbarian and Monk are essentially finished. The feat menu in particular took some effort to implement correctly. Unlike the other combat menus, it fills itself dynamically on a per-character basis, depending on what feats the given character has available. It also takes into account feats which have a fixed number of uses per day, such as Rage and Stunning Fist.

A few feats have also been renamed to more accurately reflect what they actually do: Called Shot is now Power Shot, One Shot is now True Shot and Manyshot/Greater Manyshot are now Double Shot/Improved Double Shot. I've also tweaked the behaviors of some feats to work a bit differently from their PnP counterparts: Expect Tactician works closer to the Neverwinter Nights 2 version, rather than the D&D3.5e version, while Manyshot is closer to the Pathfinder implementation.

I've also rewritten some of the targeting code to be more flexible: I noticed some inconsistencies with the earlier version due to how distances were being determined.

Now, whenever an ability has a circle-shaped (technically spherical, but we're only concerned with 2D here) effect radius, it's possible to specify to the intersection function whether tiles should have a) their center inside the circle, b) any corner inside the circle or c) all 4 corners inside the circle. This is important because even though the tile system itself purely integer-based, all of the ranges and distance calculations are still performed  in real coordinates internally, to preserve accuracy.

Another area that's had some progress was Status Effects. I improved some of the existing functionality to allow status effects to display their remaining duration along with their icons:

Effects with unlimited duration (e.g. toggled modes, like Power Attack or effects that don't wear off on their own, like Ability Damage) have their duration displayed as "∞". This now happens wherever they're displayed, be it in the status menu or above character panels in combat.

While I was in the right frame of mind to work on graphical improvements to the game, I've also added more feedback to various actions in combat by providing more information in the Combat Log:

Finally, I refactored the way classes were being stored. When I created it, I only had a very small amount of data to store and rarely had to look it up, so it was just kept in 2D arrays. With all the new class-specific behavior that I've been introducing, it became a massive pain to write a 5~10 line block of code every time I wanted to check whether a unit had levels in a given class, or what its class level was. So I rebuilt the whole thing; it's much easier to use now and most checks that used to be O(n^2) and required a several lines of code to make, now are O(n) or constant time and require only one or two lines to be written (and it's much more readable).

Finally, with the vast majority of work on Feats out of the way, I tackled the final major combat-related feature that was missing from the game: Spells!

Originally, I thought this was going to take something on the order of a month to implement because there's just so much to do. Properly implementing spells is something that touches practically every part of the game I've worked on so far: leveling, character creation, the internal actor(and enemy) structures, several menus, several parts of the database, and most of the combat system.

This is where flexible code pays off. Whenever I build a big system - the leveling system, for example - I try to make it flexible enough so I can not only maintain it easily in the future, but also make additions to it without having to rework the whole thing, or copy-paste large sections of code.

Thankfully, it seems I've done a pretty decent job at that; when I went back to some of my older code (some of it going back to about 4 or 5 months ago), it was actually fairly easy and quick to add all the spell behavior into everything - despite the fact that I figured out how exactly I wanted to implement them only recently.

So with that, I've added in all of the remaining core classes in the game, as well as most of their particular intricacies, such as differences between spontaneous and prepared casters.

There's still quite a lot of work to do, of course - even with things moving dramatically faster than I expected, it'll still probably take me another two weeks or so to have all of this properly working. But at the moment, the leveling process is working for all the available classes: you can learn spells, earn spell slots, get caster levels, increase the number of spells per day available, etc.

I've also done most of the work that was necessary in the Spells section of the main menu:

Spells can be viewed, assigned slots and removed (when applicable), as well as having correct behavior for multi-classed characters, which will have several spellbooks; it's perfectly possible to have multiple classes with different progression (e.g. a multiclassed Wizard/Cleric), classes that add progression to the same spellbook (e.g. a Bard/Virtuoso character) and classes which have different spellbooks which are drawn from the same spell list (e.g. Wizards and Sorcerers).

I still have to go back and add proper behavior for spellcasting classes during character creation (which thankfully won't be terribly hard, it's just a special case of the normal leveling process, which I've already completed), spend some time in the database adding all of the spells I plan on having for an Alpha or Demo version of the game (probably only core spells up to 10th caster level - which is still a huge number of spells), and finally add the ability to actually use spells in combat.

I'm glad Thanksgiving is coming up soon - I could use the free time to get more work done! I'm aiming to have most of the scaffolding required for the core aspects of the game done by the end of the year, so I can start working on getting an Alpha version out for people to play. I really want to start working on playable content as soon as possible. With any luck, I'll have something that actually feels like a proper game - rather than a collection of features - out by January next year.

Status Effects, Art and Music

I think I'm finally starting to get back in the groove after my break; I was getting good work done during my last update, but I've really picked up the pace in the last couple of weeks. So here's another status update, and this time it's a big one.

First of all, we now have status effects!

They're visible in the bottom right corner of the main menu, where all the placeholder status icons used to be. As you can see from that screenshot, it's a scrolling window now, meaning you can move the cursor over to it and see however many status effects you're affected by.

Not only that, but I've also re-worked the Summary menu help window to look a little cleaner and function with the newly implemented status effects, giving you some pretty detailed information about what's going on.

This was actually quite a bit of work. If you've ever used RPG Maker, you know it doesn't actually support storing all of this information about status effects anywhere. To get this to work, I've actually implemented a completely different system to handle the game's status effects.

A base class defines all the common features of status effects - applying/reappliyng/removing/etc. , as well as their interface.


Each effect is then represented by a class that inherits that, which can then have whatever behavior I want it to have, and hold whatever information I need it to hold. The fact that I can no longer edit them from VXA's database is a small price for the huge amount of flexibility I get with this.


The following effects were implemented:

• Flatfooted
• Prone
• Fatigued
• Exhausted
• Nauseated
• Asleep
• Dazed
• Stunned
• Fascinated
• Blinded
• Deafened
• Entangled
• Shaken
• Panicked
• Paralyzed
• Unconcious
• Dying
• Dead
• Haste
• Slowed
• Ability Damage (Strength, Constitution, Dexterity, Intelligence, Wisdom and Charisma)
• Disease (Red Ache, Shakes, Mummy Rot, Mindfire and Cackle Fever)
• Poisoned (Aranea Venom, Huge Spider Venom, Colossal Spider Venom, Ettercap Venom, Arsenic, Giant Wasp Poison, Phase Spider Venom, Black Lotus Extract, Epic Wyvern Poison, Id Moss, Striped Toadstool, Chaos Mist and Ungol Dust)

These all include most of the various special D&D rules regarding combat behavior while under these effects, such as not being able to Run while Fatigued, and Ability Damage recovering slowly every time you rest.

I haven't implemented every single disease and poison effect in the D&D3.5 SRD because for the most part, I think it's unnecessary (there are dozen and dozens of them). I've included at least one affecting each base ability score, so they all have their own specific purpose. I might add more later if people really think it's necessary, but for now I think a handful of each type should be more than enough.

One other interesting thing to point out, which I realized while developing this whole system for status effects is that in general, the duration for any given effect varies based on how it was caused. Spells, for example, have a duration that's usually based on the caster level of the unit casting it. On top of that, there's other things which can modify it, like Metamagic. So I need some way of saying "by the way, this Haste spell has Extend Spell on it and lasts longer than normal!".

Thankfully, there is an easy way to do this in Ruby, though it requires a little bit of work to setup. Thanks to this post on StackOverflow, I've found out that you can actually model enums as objects in Ruby and use them to represent bitflags. So I can write something like this:


Then all I have to do is pass this around, if say, I want to have a spell with Empower and Maximize on it:


And checking it becomes trivial:


This makes handling all of the various possible ways status effects can behave actually fairly easy. That's about all that's been going on in that front. After wrapping up status effects, I resumed working on the combat system and started filling out all of the previously unimplemented actions. All of the following are now available in combat:

• Aid Another. Minor change: all Aid actions have been fused into a single action. This means that whenever you "Aid" an ally, they gain both the AC bonus and the attack bonus. Additionally, if they're Asleep or Fascinated, those status effects are removed. This helped me get rid of the clutter from the combat action menu; three different Aid actions was too much.
• Trip
• Disarm. Minor change: when a unit is disarmed, their weapon automatically gets returned to their inventory, rather than being dropped on the ground per PnP rules. This means the target can re-equip their weapon after being disarmed, though it will use up their action for that turn.
• Coup de Grace
• Feint. Minor change: any unit that attacks the target gets the bonus, not just its user. The effect still disappears as soon as target is hit, regardless of who hit it.
• Total Defense
• Run
• Charge
• Bull Rush

With status effects available, most of these were fairly straight forward to implement, with a coupe notable exceptions: all the actions that depended on moving in a straight line (so Run, Charge and Bull Rush) required a little more effort.

The problem comes with how I've been handling movement so far. Until now, I've been using a modified version of Dijkstra's Algorithm for path-finding, which works out really well for a tile-based engine like RPG Maker, because a network of tiles can be easily represented as a graph. It's great whenever you need to find the shortest path from A to B, while avoiding any obstacles (i.e. impassable tiles, tiles occupied by enemies, etc.) on the way. It's not very good at straight lines, though.

How would you use it to get the tiles represending a straight line from any given tile to any other tile? The algorithm explores the surrounding tiles in a breadth-first fashion.

The thing about straight lines is that - outside of directly going in one of the 8 directions - it's actually non-trivial to figure out what the "straightest" straight-line path is from any tile to any other tile. So I needed to come up with a way of mapping any straight line, in any direction or angle into actual tiles. Turns out Bresenham's Line Drawing Algorithm is perfect for doing exactly that.

So I wrote a second path-finding algorithm based on that. Given any two tiles, it will find the most optimal way to turn a straight line between those tiles into an actual walk-able path of tiles, then check whether that path can be traversed. The only minor wrinkle in it is that the algorithm was originally created to draw pixels on a screen, and you generally don't care about in what order that happens, so sometimes it gives you the list of points out of order, depending on the slope and direction of the line.

I do very much, however, care about order when walking on tiles in a path, so I've had to make some minor adjustments. Given some fairly simple changes, though, the whole algorithm works out quite well.

Finally, I've made a few changes on the art & design front. First of all, I've simplified a few areas of the game by getting rid of the Grapple mechanics (I think it's unnecessary and most people hardly every use it), the ability to run away from battles (Save often!) and I've halved the range on all ranged weapons.

That last one takes some 'splainin. The thing with RPG Maker that annoys me the most is the incredibly tiny resolution you're limited to. Since I'm essentially making a tile-based SRPG and measuring distances in tiles, this means I have a fixed amount of the game's coordinate space I can ever actually display on screen.

The means that even though some distances make perfect sense in D&D, they're actually really large when you move them to RM. For example: ranged weapons have 3 (roughly) important ranges: 30ft (hand crossbows), 60ft (shortbows) and 100ft (longbows). If you represent each tile as 5x5ft, those turn into ranges of 6, 12 and 20(!) tiles away, respectively.

If you've ever made a map in RMVX or VXA, you know that's a lot of tiles. For the sake of comparison, you can only actually fit a region of 20x15 tiles on screen at any given point. So a longbow would always be able to reach anywhere visible on screen, and then some. That's way too much. I can't ever imagine having combat maps which are big enough for that to actually be relevant. So I've decided to half all of those ranges, bringing them down to 15/30/50 ft - or 3/6/10 tiles, respectively.

I think that's a much more reasonable scale. If you've ever played Final Fantasy Tactics, you'll recall that ranged abilities also had 3 major ranges: 3 tiles (wave fist, most sword skills, other melee ranged abilities), 5~6 tiles (bows, magic) and 8 tiles (guns). I think that's a fairly good scale.

Last, but definitely not least, the game finally has a logo and a title screen, thanks to Archduke on the RPG Maker Web Forums:

Speaking of RMWeb, I've also joined their Game Making Drive. I'll be posting daily updates in the Drive forum thread:

GO TEAM RALPH!

Aaand, that's all folks. Stay tuned for more updates. For now, I'll leave a hint of what I'm working on next:

A Break, more Combat Updates and...Art?

So, in the last couple of months I've taken a bit of time off to sort out various issues that prevented me from having quite enough free time to keep working on the project at the pace I had during the summer.

In the meantime, I took what time I had and decided to use it to go through other games similar to this project and sort of compare notes - see if there's anything I hadn't planned for or had forgotten to address. I did actually end up coming up with quite a lot of extra notes, but I don't want to quite post out here what they are yet until I'm ready to start working on them, which should happen after combat is mostly finished.

That time is mostly over now, thankfully, and I'll be getting back to work on this very soon. In fact, speaking of combat, I have a few extra updates to showcase since the last post I made.

First of all, I've completely overhauled the visuals. It now (hopefully) looks like a proper combat system, rather than a bare-bones tech demo.

There's now a combat log in the bottom right, which displays some basic information about all actions in battle, and the portrait windows should now be easier to read. In addition to cosmetic changes, I've also implemented several of the basic combat mechanics:

Characters can now use most forms of movement, including the basic move action, 5ft steps and the withdraw action. The blue set of tiles displayed is the character's basic movement range, while the yellow set of tiles are the squares they threaten.

Any unit walking within those yellow tiles will trigger an Attack of Opportunity, which has also been fully implemented. Units' threat ranges vary based on what weapons they currently have equipped.

As you can see from the screenshot, attacks have been implemented as well, both in the form of single attacks and full attacks. These all correctly handle two-handed weapons, dual wielding, double weapons and ranged weapons.

I've also implemented a basic targeting system. Each action that can be performed in battle has a particular type of targeting. The targeting system allows actions that target not only single tiles, but area effects in various shapes, such as circles, cones or lines of tiles. This will be more relevant once spells are implemented.

Combat can actually be finished now, so you could say this is the first time the game has an actual proper combat system. Experience is awarded based on the difficulty of each opponent defeated and split between the player's party. Additionally, enemies have their own inventories, and you automatically obtain everything they were carrying at the end of combat.

I've also added a few nice details to make the combat feel smother, such as a damage preview window whenever a player unit targets another unit with a hostile action. This way you have some idea of whether it's worth it to perform a given action before committing to it.

And that's all for now! Next up, I'll be implementing status effects so that actions like bull rushing and tripping are possible, in addition to the obvious applications, such as the ability to poison enemy units or buff allies.

I'm also looking into changing the game's art style into a more grainy, old school 2D western RPG type feel (think Ultima Online), provided I can get the support of an artist willing to put in the work.

I can't say anything for certain about that quite yet, and even if I do make the change, it won't happen for a while, but look forward to further news on that front in the future!