A Proper Explanation – Navigating Love’s Battlefield

Battlefield of Love Placeholder Logo

I’ve waited long enough. It’s time I finally clarify what Battlefield of Love is supposed to be. All I’ve really explained so far is that it’s an RPG, as well as why I had to shelve The Turtle Who Had Wings for it.

Well, it’s based on the posts on what my dream RPG would look like. Based on. I’m not conceited enough to think I could make anything resembling my ideal game immediately. Today, I will be discussing the battle system only. That shouldn’t be a problem, since it’s the meat of most RPGs.

I should note, a playable in-development prototype will be linked at the end of this post. If you don’t understand something, just try it out for yourself.

The concept is simple. You have 8 party members and move around an arena like in, say, Grandia, and kill things. I also took a page out of the Atelier series’ playbook and decided to allow party members to take hits for other characters. I also wanted them to do supporting attacks, but such a mechanic broke all of my code, so I’ve put that aside to only be implemented if I have time to figure things out.

Now, an 8-player party sounds like it would be aggravating to control with how many turns would pop up in a row, wouldn’t it? You’d be correct. This GIF below shows how things looked at the end of September, before I’d implemented the vast majority of things. Drives the point in just fine:

BoL Prototype GIF 1 (September 28, 2014)
It doesn’t look anything like this now.

Because of this, I decided to split the party into two groups of four. One group (characters in a “Main Role”) has normal turns, the rest (characters in a “Supporting Role”) exist outside of the turn order and may be commanded to perform a move at any time.

Some other things I’ve done include removing MP, opting for something along the lines of Tales of Graces‘ Chain Command mechanic. Each character uses Command Points (a simple number between 0 and 99) to perform moves, and it restores itself over time. I’ve also adjusted how levelling up works. Only half of the stat distribution is pre-set, the rest being entirely based on the actions one performs in battle. And this stat distribution is important, since attacks can generally only miss based on your stats – no random missing here unless it’s an inherent part of the move, you’ll either always hit or always miss. There are ways to hit or be hit despite that, however.

I suppose the final implemented mechanic I should mention is how I’ve laid out status ailments. They’re far harsher (and thus more useful) than most RPGs, and I intend to make most bosses vulnerable to the lion’s share of these. Along with the removal of random missing, I decided to de-emphasize luck with these. The ailments in question, with descriptions taken straight out of the game design document:

Positive Status Ailments

  • Vigor: Raises all stats except HP by 25% of the base value. Can stack up to three times. This and Weakness cancel each other out.
  • Regeneration: HP and CP restore at a rate of 10% of the maximum per turn. This happens before Poison damage and before the player has a chance to select an action.
    • If the character is in a Supporting Role, this is changed to restoring 5% of the maximum HP each time an ally with a Main Role has a turn.
  • Ailment Barrier: Prevents a negative status ailment once, then disappears.

Negative Status Ailments

  • Sleep: Character cannot act until woken up. Any incomplete actions are cancelled (so the character simply begins Waiting upon waking up). Sleeping characters are considered Busy.
    • Methods of waking up include intervention by other party members, being hit by an attack, or other characters/enemies successfully attacking or being hit by an attack within their Alertness Check’s range. A character cannot wake up by simply waiting for time to pass.
    • Hitting a Sleeping target deals double damage and ignores any and all defensive boosts or effects that lower damage, with the exception of elemental resistance.
  • Poison: This ailment advances through various stages, from 1 to 10. The ailment can be inflicted at a specific stage, and any attempts to Poison an already-Poisoned character will instead increase the stage by the level that would have been inflicted.
    • If the affected character is in a Main Role, the stage advances by 1 after each time poison damage is dealt. If the affected character is in a Supporting Role, the stage advances by 0.25.
    • A character in a Main Role loses (10 × Current Stage of Poison Rounded Down)% of their max HP at the start of each of their turns. This damage is dealt before the player has a chance to select any actions, but after any healing from Regeneration.
    • A character in a Supporting Role takes damage based on the same calculation, but on the turns of each character in a Main Role instead. Also, the damage is divided by 4.
    • By this math, if a character is inflicted with Stage 1 Poison while at full health, and does not otherwise heal or take damage, the character will be knocked out by the damage from the Stage 4 Poison, just as the Poison advances to Stage 5.
  • Paralysis: Every third turn is skipped for this character. Can be stacked up to three times. If stacked twice, the character can only act every third turn. If stacked three times, the character cannot act until it wears off. Each stack of the ailment wears off at a separate pace, dictated by whatever inflicted the ailment in the first place.
    • If the character is in a Supporting Role, there is instead a 33% chance of failing to perform an action per stack of this ailment. Failing to perform an action will still spend the Teamwork Gauge.
  • Blind: DEX and ALT stat values are both treated as 1 until it wears off. The ailment wears off at a pace dictated by whatever inflicted the ailment in the first place.
  • Silence: Magical attacks cannot be used until healed.
  • Distracted: Each turn takes twice as long to reach. The ailment wears off at a pace dictated by whatever inflicted the ailment in the first place.
  • Weakness: Lowers all stats except HP by 25% of the base value. Can stack up to three times. This and Vigor cancel each other out.

The resulting battle system can have a lot going on at once, but is also very easy to navigate.

To prevent this from getting too long, I’ll cut myself off here and just show the prototype build.

Trying the Prototype

The prototype can be tried here. It runs in your browser, though you’ll need to have the Unity Web Player plug-in. I should note that, if you’re reading this in the far future, the prototype may have been taken down to free up Dropbox space.

Everything is controlled by the mouse except the left and right arrow keys let you switch between displaying the two sets of characters you control at the top. All art and sound assets are obviously placeholders from various royalty-free sources.

I should also note a known issue with this build. At seemingly random points, a menu may open and close before you can do anything, and the characters would seem to no longer be moving. I’m trying to track down a fix for it, but you can resume for now by opening and closing the support menu. If that doesn’t work, open the support menu and command someone to do something.

In any event, I’d gladly take feedback on this prototype (provided I’m not so much farther along that there’s a newer one up or something – use your head). If there’s anything that seems to be wrong, this is the best time to speak up so I can take it into account. Just note that several things have not yet been implemented.


2 thoughts on “A Proper Explanation – Navigating Love’s Battlefield

  1. I felt the gameplay was pretty decent.

    It didn’t feel like I actually dealt ANY damage to the Goblins – so I would put more emphasis on what I had achieved, not what I had lost. “Critical Hit”, “Super Slash”, stuff like that.

    It looked like a boolean was not/set somewhere for the menu. Something of that order.
    The “fix” does not work once you are down to 4 players. word to the wise.

    All in I enjoyed the mechanic – however felt that simply having a shortcut key for “ATTACK” would have been more gratifying than all that clicking.

    • Thank you very much for the feedback.

      Yeah, I have the glitch corrected in the latest internal build. There were disorganized changes to the game speed all over the place, so I simply moved them all to one place and found the issue in the process. Since it’s all in one place now, it’ll also be far harder to have the problem again. (The issue was that the game speed was being set to “0” somewhere unnecessary.)

      And yeah, not feeling like anything was achieved is a common complaint. The game lacks any critical hits (as a deliberate part of the design), but I intend to add health bars for enemies and clear damage numbers.

      As for the repetitiveness of clicking “Attack”, that’s only for now. The final game will have all of those grayed-out options on the menu actually available, so I suspect the menu staying as it is will be helpful for those who want to use skills or items (both of which will be fairly necessary). But shortcut buttons for commands does still seem like a good idea to remove the need to go through layers of menus. Thanks for the suggestion.

Comments are closed.