Together, they simplify the game’s battle interface. The re-positioned windows keep the player’s focus closer to the relevant actors.
Actor’s actions appear right next to their sprite.
Actor’s health and mana is located just to the right of them.
Targeting an actor will cause their status window to slide forward slightly. By a happy coincidence, their character portrait in the timeline display also bobs upward. It makes the interface feel cohesive.
But it’s not flawless. As you can see, when the 4th party member chooses their action, their status is partially obscured.
An enemy’s name, health, and status ailments are shown when you target them.
The plugin also adds new functionality, showing an icon for each of the enemy’s potential weaknesses. Strike the weakness, and it’s revealed so you can remember for next time. Without this type of interface, enemy weaknesses are not signaled clearly enough to be viable.
The game’s systems have plenty of complexity in other areas, so cutting down the variety of equipment is a way to keep the game from feeling unnecessarily complex.
I’ve also made it so bows no longer require quivers to work. It was a cool idea, but the complexity it adds is not necessary, and it would have been a challenge to elegantly communicate to the player that quivers and bows can only work together.
I’ve added Galv’s Equip Item script. By default, all actors share the same inventory, and can use as many items as they want from the inventory. This script makes it so actors can only use items that have been manually assigned to them.
With only 6 items available per character, it could add depth to each combat. Or if could add a painful amount of time spent in the menu re-equipping items between battles.
To mitigate the latter issue, I’ve made a script that automatically re-equips items to a character after battle, if the party’s inventory has extra copies of the item.
I’ve also been playing around with making items that are not consumed permanently, but can only be used once in battle. This makes healing functionally unlimited, but the player can’t heal indefinitely each encounter. It’s inspired by the estus system in Dark Souls, but it remains to be seen if my execution is nearly as elegant.
I’m planning to give players access to a bestiary that keeps track of the enemy monsters in the game.
Random mobs might have to be fought before they’re added to the bestiary. But I think it might be useful to add upcoming bosses to the bestiary before the player encounters them. This scheme will give players an optional heads-up of the next big foe and will let them prepare for it.
There are multiple abilities in FCQ that rely on complex formulas. For example, Focus Strike is an ability that boosts your physical damage according to how much MP you have remaining.
While you could look at your remaining MP amount and try to calculate the resulting damage boost, that’s impractical. So I’ve started using state indicators to show the bonus damage as a percentage.
The icon art isn’t final, but it’s a good step in the right direction!
I got rid of the Hunter line and consolidated their most interesting skills into the other jobs. Here’s why…
I recently watched video gameplay of a MOBA, and I admired the well-defined roles of each character class. In that genre, the most common roles are DPS, Tank, and Support.
Single-player RPGs tend to allow more complexity in their character roles, perhaps because of their solo nature; with no team depending on you to play well, there is no urgency to understand each character.
In FCQ, each job has a unique theme. They broadly fall into the same categories mentioned above, but there are outliers.
Brawler line: Physical fighters/Tanks
Medic line: Buff/Heals
Thief line: Debuffs
Page line: Magic DPS
Adventurer line: Quirky non-standard skill costs, mix of physical fighters and buffs
As for the Hunter/Ranger/Sage line of jobs… I don’t know what describes them. Each had radically different abilities, with little to connect them. I liked the idea of a class focused on bows and traps, so the Hunter was one of my favourites thematically. But I was never satisfied with the other two classes, nor their tenuous connection to each other.
As a rule, all classes in FCQ are limited to 4 active skills.
This is a design constraint to keep each skill useful. In FCQ, you won’t have the equivalent of a level 1 Fire spell cluttering your skill list after you’ve learned the much superior level 3 Firaga.
It also keeps battles feeling snappy. Find your skills in 2 clicks. No scrolling required.
Equally important, this restriction is also to keep me sane. Even with only 4 skills to a class, but over 20 classes, that’s still a lot of skills. It’s plenty of work to conceptualize and balance them all.
With one exception
However, there was one area where this limitation felt… well, too limiting. My Ranger class has the ability to manipulate the elements. Since there are 4 elements, there are 4 related skills. That’s all. Just 4 support skills that are identical, except for their elemental affinity.
My workaround, while staying true to the rules, is to give the Ranger a toggle skill. Using Desert Camo or Swamp Camo will swap between two sets of 4 moves each.
Embed (elemental support)
Submerge (elemental support)
Ambush (new)
Desert Camo (toggle)
and
Parch (elemental support)
Levitate (elemental support)
Survival (new)
Swamp Camo (toggle)
A decent compromise
It’s slightly clunkier than just putting more than 4 skills in a scrolling list, since it takes a couple seconds to use the toggle skills. But I’m willing to accept that speed-bump since it keeps the menu behaviour consistent and gives the class a unique quirk.
Dual-wielding is the concept of holding a weapon in each hand instead of a weapon and a shield, or a two-handed weapon. It’s a fun way to give your characters more options for customization. The problem with the way RPG Maker MV handles dual wielding is that there’s no visual feedback from it. Your attack animation still only hits one time, no matter how many weapons you hold.
Plugin woes
I’ve been using a plugin to fix this issue. But it’s been giving me grief, randomly changing my character’s stats between each weapon swing and leaving them permanently altered. The plugin’s support was shaky anyway, so rather than spend time troubleshooting, I looked for an alternative.
It does what it should quite elegantly, allowing the user to swing each weapon individually and letting those hits have different strengths depending on the weapon’s strength. I added a few extra features to it, including
a check to see if the weapon fires long-distance, or if the player should approach their target before the attack begins.
a check to see if the user is carrying two weapons (so it acts like a regular one-hit attack for users with one weapon).
a check to see if the 2nd weapon has a different animation than the first (otherwise it just repeats the first animation).
Sample code
Here’s the snippet in full:
// M.o.v.e. forward a little i.f. firing a missile
if user.attackMotion() == 'missile'
move user: forward, 48, 10
wait for move
else
// M.o.v.e. to the target
move user: target, front base, 10
wait for move
end
// I.f. the user has multiple weapons + dual-wield
if user.weapons().length > 1 && user.isStateAffected(129)
EVAL: user._weap1 = user.weapons()[0];
EVAL: user._weap2 = user.weapons()[1];
// Unequips second weapon
EVAL: user.forceChangeEquip(1, null);
// 1st weapon attack
MOTION ATTACK: user
MOTION WAIT: user
action animation
wait for animation
action effect
EVAL: user.forceChangeEquip(0, user._weap2);
// 2nd weapon attack
MOTION ATTACK: user
MOTION WAIT: user
// animation of 2nd weapon
EVAL: target.startAnimation(user.weapons()[0].animationId);
wait for animation
action effect
// Restores weapons
EVAL: user.forceChangeEquip(0, user._weap1);
EVAL: user.forceChangeEquip(1, user._weap2);
else
// Regular 1 weapon attack
MOTION ATTACK: user
MOTION WAIT: user
action animation
wait for animation
action effect
end
The weird dots in the comments are because action sequences don’t have the concept of comments. So if I didn’t put dots in between the letters of “i.f.” it would be interpreted as a programmatic if statement.
A job (aka class or role) is a specification used to define a player character’s skills, abilities, and stats.
Iteration 2
Earlier draft of the job tree. Freelancer was a separate job with no antecedents. Apparently I planned to have Necromancer related to Alchemist.
The freelancer became a prereq job.
The magic jobs were renamed to emphasize their similarity.
The magic jobs got a third stage in their tree.
Stareomancer became the much less magical-sounding Ranger.
Iteration 3
Freelancer became Adventurer, which shifted over to a prereq for the magic jobs. Their third stage was removed. (The fewer exclusive jobs, the better.)
All jobs were normalized to have a level 3 prereq.
Iteration 4
Merchant and Alchemist lost their Mir-exclusive status, and became part of the Adventurer tree. (Again, the fewer exclusives, the better.)
Page was a new job added as the first stage of the magic tree. It then branches simply with each player character getting their own variety of Channeler.
Recently I’ve been playing Final Fantasy Tactics Advance A2, and I’ve been appreciating their relatively low numbers. The highest HP I’ve seen in the game is around 700 total.
So, for FCA, I’ve reduced all of the playable character’s max HP by half.
It’s much too early to balance the game, but the original values were clearly off. End-game bosses needed to take three turns to kill a completely unequipped player character. That’s far too much.
Examining damage to HP ratio
The formula for most damage in the game is:
Math.power(a.atk, 1.5)
Or, in English:
The battler’s attack stat to the power of 1.5
That means, even at the soft cap of 99 ATK, an enemy’s skill would deal 985 damage against an unarmoured target.
In the early days of development, the highest HP class in the game had 5300 HP. That’s now down to 1300, and the lowest HP class now has 540. Now we’re looking at the possibility of characters being tanks or glass cannons.
Creating more varied gameplay
Lowering HP should have the effect of increasing the value of armour, which is good. I don’t want players to have to grind too much for anything in particular. So I’ll split the burden of empowerment between gaining levels and gaining gold to buy equipment. It’s not much, but it’s a start to increasing diversity of the standard gameplay loop.
