RMMV Grid Battle System (early access test: tile states)

[Tsukihime]

Itch page: https://himeworks.itch.io/grid-battle-system
If you want to follow the development.

Public Testing #1 - https://itch.io/t/912596/public-testing-1
Very simple compatibility test to see if you can add it to your project. Feel free to try it out.

Public Testing #2 - https://itch.io/t/929529/public-testing-2
Some extra plugins that let you try out one grid or two grid battles, skill ranges (for two grid), and a basic "move" command.

There's also an online demo version http://game.himeworks.com/grid/
Note that mouse may not have been fixed in this version depending on when you're playing it, because the plugins didn't have proper mouse support at the time.

Dev Logs

Devlog #1: Added a grid! - Grid Battle System for RPGMaker by HimeWorks

Here's an update on my grid battle system that I've been working on. 1. I integrated the grid with the battle system successfully. 2. I added some basic logic for AoE skill targeting. When you select...

himeworks.itch.io

Devlog #2: Movement and Summons - Grid Battle System for RPGMaker by HimeWorks

In the last progress update , I had implemented support for "grid selection". That is, you were able to select a tile on the grid directly instead of selecting actors or enemies. Consider this cross-s...

himeworks.itch.io

Devlog #3: Basic Skill Range - Grid Battle System for RPGMaker by HimeWorks

Today I wanted to talk about "skill range". What is range? Range is basically an upper and/or lower bound of some sort of scale. In our grid system, we are interested in the "distance" between two obj...

himeworks.itch.io

Devlog #4: Multi-Target Selection - Grid Battle System for RPGMaker by HimeWorks

One of the next features I wanted to work on was the ability to select two more targets for a skill. In RPG Maker, this isn't really an Example Your party finds themselves looking at a river, but the...

himeworks.itch.io

Devlog #5: Grid Configuration Management - Grid Battle System for RPGMaker by HimeWorks

Today I wanted to talk about Grid Configuration Management . Basically, how do you manage your grids in your game so that it'll be exactly what you want for your battles. What is a grid configuration?...

himeworks.itch.io

Devlog #6: Area of Effect + Region Painting - Grid Battle System for RPGMaker by HimeWorks

Today I want to talk about area of effects. Specifically, I want to talk about how area of effects will be created, and the motivation behind the input format. Creating Area of Effects When it comes t...

himeworks.itch.io

==================

I've been doing some grid-related work and one thing that seemed useful was to add the concept of "positions" into the default battle system. I did some quick tests to see if I can display sideview actor sprites on a grid, and it seems to work. Here's a video example of what I mean, assuming we have a battlefield shaped in a 3x6 grid (3 rows of 6 spaces, assuming vertical rows)


This topic will mostly be to discuss ideas that could be built into a battle system that has positions.

Battle Formations

We can start with the idea of a "battle formation" which is a pre-determined set of positions for each battler. So for example, maybe they all stand in a straight line at the front of the grid. Formation can simply be for visual purposes. You might have some sort of formation bonus like extra attack or extra defense. You can manage "formation bonuses" via states, which might make set up a bit easier.

Battle Rows

Given that we have positions, we can then define what a "battle row" is. You could have a "back row" and a "front row" in a 2-row system. This is basically what older final fantasy games had. You could define a state "back row" and another state "front row", and each state basically controls what kind of bonuses you might have. Maybe backrow takes less damage from attacks but also deals less damage when attacking.

Battler Direction

With positions, you can now define what "direction" means. For example, you can have two battlers "facing each other", or "facing away from each other", or "facing from the side". You could potentially have damage bonuses based on the directions the targets are facing, relative to where the attack is coming from.

This can lend itself to "back attacks" like the ones in final fantasy, where your characters are all facing away from the monsters and therefore take additional damage.

You can also implement "pincer attacks" where enemies appear on the left and the right side, and of course your battlers can only face one direction at a time so one side will always be vulnerable.

Movement System

With positions, you could potentially add movement to your game.
This is different from a simple "back row, front row" system where you just move back or move forward. With a movement system, you could actually move to a completely different position on the field.

Area of Effect

A skill could have a custom "area of effect". Maybe it targets one square. Maybe it targets an entire row or column. Maybe it targets a cross shape. Or it targets the entire field. Lots of options here.


Grid Selection

Basically, if you want to select tiles on the grid. This can be used for various things like picking a square to move to, choosing an empty square as the "center" of an AoE attack, and so on.


Attack Range

By default, we don't have a concept of "attack range". If you want to attack a monster, you just select it and then the attack will go through. However, with positions, you now have a way to describe the "distance" between two battlers, and therefore the "attack range" determines how far the target must be.

Depending on your game, you might have different implementations of range. For example, maybe "1 square" means you must stand in the front row, and you will only be able to target enemies that are also on the front row.

Single Grid vs Separate Grid

In the video above, all of the actors are confined to their own grid.
The enemies would presumably be on a separate grid, and they can't cross over to each other.

But this isn't completely necessary. You could combine the grids together so that the battlers can freely move anywhere, like this:



Combine things like "attack range" and "area of effect skills" and movement system, and now we have enhanced the default battle system by simply having positions.

What are some other features that might be cool?

Note that every feature will be developed separately. You would be able to mix-and-match features that you want. This would give you more flexibility over how you want to build your battle system.

 

[Synrec]

Is this like Yanfly's row formation script?

 

[Astfgl66]

I did someting similar by customizing Yanfly's row plugin. I basically copied his code and modified it to add a vertical row property that allowed me to effectively make a complete movement system.
The actually difficult parts for me were adding terrain effects (planting a mine, designing some squares as damage tiles) or creating difficult/impassable terrain.
The system works but I never got far with it because I couldn't create an enemy AI worth a dawn so it was doomed to be uninteresting. Freedom of movement for the player but not the enemy would not have been very interesting.

In the end I decided that it was just like creating a fire emblem game and that if I really wanted a 2d battle system on a grid, using a SRPG plugin was probably best, because in addition to all that you have already written you get actual terrain, pathing, line of sight, elevation, terrain effects, enemy AI and more included in the package already.

If I end up reusing this idea again, I think I'll stick with a separate formation for enemies and actors, and differently shaped AOEs. That and having different part of the grid provide different buffs should provide for an interesting layer of strategy.

 

[jerrypylant]

This almost seem kinda like a "Lunar" style battle system(Lunar Silver Star Story Complete)

 

[Tsukihime]

Is this like Yanfly's row formation script?

I'm not sure how many features yanfly's row formation script has, but I assume there would be some overlap.

The actually difficult parts for me were adding terrain effects (planting a mine, designing some squares as damage tiles) or creating difficult/impassable terrain.

Terrain effects would be interesting. My design has it so that each tile can be individually tracked, so adding terrain effects might simply be adding some properties to each tile.

Impassable/rough terrain would be similar idea, just properties attached to each tile.

The system works but I never got far with it because I couldn't create an enemy AI worth a dawn so it was doomed to be uninteresting. Freedom of movement for the player but not the enemy would not have been very interesting.

Ideally I would leave AI up to devs. That way I don't need to worry too much about how to make a good AI lol. RPG Maker has a very simple AI setup for example with action priorities and conditions.

The AI logic could be as simple as "can I attack? No? Move towards closest/weakest target"

In the end I decided that it was just like creating a fire emblem game and that if I really wanted a 2d battle system on a grid, using a SRPG plugin was probably best, because in addition to all that you have already written you get actual terrain, pathing, line of sight, elevation, terrain effects, enemy AI and more included in the package already.

I think if someone was basically building a fire emblem game, it would definitely be better to just grab one off-the-shelf. However if they wanted to integrate certain aspects, might be a bit more challenging.

I'm going with a "mix-and-match" approach, where devs basically start with a grid and then decide what they want to include in the game.

 

[Dororo]

That grid system is "Live A Live" combat, if you want some reference. It wasn't well rendered (become interesting just in the ending part of the game), but own interesting ideas: all battlers got area of effect for attacks, so you can try to move to safer spots. Long ranged weapons got an actual meaning. Large creatures determine obstacles on their own and own sensible spots you had to reach.
AI is quite "dumb", opponents attack on a routine, but this can be seen as a kind of puzzle to solve.

Adding more features sound to me like shifting to a tactical combat engine, probably not your original idea.

 

[Aerianr]

I'm in love with this idea already! I've been fighting with Yanfly's row formations plugin for days now but it just isn't quite what I'm looking for. I especially love that the ability for back attacks or pincer attacks would be included.

Personally, the most important thing to me would be ease of positioning characters and enemies. There are a lot of issues with this in Yanfly's plugin (which is the only row formation plugin available), like when enemies or allies switch rows, the entire formation gets shifted in an unintended way that is confusing to look at (rows aren't obvious anymore).

Hopefully this is something that could be controlled within the menu, and if that's the case, the ability to handle formation/party order and row configuration all in the same spot would be fantastic. And within battle, the option to not only switch rows would be good, but also the option of it using up your turn, or even just a cooldown effect so it can't be spammed.

This is seriously a great idea and I'm going to be watching like a hawk for when it's ready.

 

[Tsukihime]

That grid system is "Live A Live" combat, if you want some reference. It wasn't well rendered (become interesting just in the ending part of the game), but own interesting ideas: all battlers got area of effect for attacks, so you can try to move to safer spots. Long ranged weapons got an actual meaning. Large creatures determine obstacles on their own and own sensible spots you had to reach.
AI is quite "dumb", opponents attack on a routine, but this can be seen as a kind of puzzle to solve.

Adding more features sound to me like shifting to a tactical combat engine, probably not your original idea.

Large creatures would be interesting. Currently I'm not sure how that might be implemented, but I've seen games where a single boss might take up 3x3 grid, and so if you have an AoE that hits any part of the enemy's space, they would get hit.

From a different angle, take a classic hydra example. Perhaps it might be a single massive sprite, but each head occupies a different square.

As for tactical combat engine, this plugin suite could potentially be used to implement one as well. It's the same kind of mechanics after all, just the way they battle process is presented to the user is a bit different.

Slap on a grid, enable movement, then allow players to freely select which actor they want to perform an action (instead of based on some fixed order determined by speed, etc). To me, that already captures the essence of Strategy RPG. It's basically fire emblem heroes.

1. I especially love that the ability for back attacks or pincer attacks would be included.

2. Personally, the most important thing to me would be ease of positioning characters and enemies.

3. Hopefully this is something that could be controlled within the menu, and if that's the case, the ability to handle formation/party order and row configuration all in the same spot would be fantastic. And within battle, the option to not only switch rows would be good, but also the option of it using up your turn, or even just a cooldown effect so it can't be spammed.

4. This is seriously a great idea and I'm going to be watching like a hawk for when it's ready.

1. We could take it a step further as well. Let's say part of your story, the party decides to take a rest in the forest. Then one of the members hears a noise and runs to check what it is, and then you find out it's a monster.

You could set it up so that the "battle" reflects the story, where you set up the positions in the event before starting the battle:




2. For a rectangular grid (the only grid I've been working with. Haven't worked on other kinds of grids), it'll be "row column" designation. It might look something like this

battleManager.setPartyPosition(1, 3, 4)
battleManager.setPartyPosition(2, 6, 7)
battleManager.setPartyPosition(3, 2, 2)

So assuming your game only has 3 party members, you could event custom positions for each battle quite easily. You could do this for troop members as well in a similar way.

3. A menu could be built on top of the formation system if that's something you want for your game. It would be provided as a separate plugin, so that devs can choose whether they want to have that kind of menu or not. Maybe I only need the formations to have back/pincer attacks, which wouldn't need to have this kind of menu for example from star ocean 2



4. Since different features will be developed separately, I think once I have the "basic" grid added to the default battle system with maybe one or two add-ons built, could begin testing for compatibility issues with other plugins like yanfly battle engine, etc.

 

[Tea's Jams]

Twitter feeds are a mess always...

This looks very interesting

 

[Solar_Flare]

I already wrote my own custom formations system, but this sounds like it will offer a lot more features. Will it be done for MV? If so, I'll definitely keep an eye on it.

 

[Tsukihime]

Some updates.

1. I integrated the grid with the battle system successfully.

2. I added some basic logic for AoE skill targeting. When you select a target, it'll display the area of effect. When you confirm your selection, the game will search for additional targets that are within the area of effect, and then execute the skill/item on them as well.


3. I added some basic logic for grid target selection. When you select a skill that requires target selection (any skill/item that has a scope of "one enemy, one ally, the user, etc), the game will ask you to select a target as usual. However, instead of opening the actor or enemy windows, the game will activate the grid selection.

When you pick a square, the game will confirm that as your selection, it will use the area of effect skill targeting logic above to see if anyone gets hit. If there's no one there, you'll basically perform your action but nothing gets hit.


Now that grid selection is complete, the next feature that will be added is a move command, where you can select the "move" skill, which will activate the grid selection (as in #3), and when you pick a tile, the game will then initiate the movement sequence (which might be just teleporting to that spot, or the actor might need to run there, etc). Because the "move" command is just a skill, you can also have it consume mp, define range (that will be implemented later), and so on.

Attack range can also be implemented now, with the new grid selection. If your actor can only attack an enemy beside them, you won't be able to select squares that are "outside of your range".

Direction is still something that would take some thinking, because it's pretty much a separate system. Also because our side-view sprites don't have frames for "facing north" or "facing south".

I already wrote my own custom formations system, but this sounds like it will offer a lot more features. Will it be done for MV? If so, I'll definitely keep an eye on it.

Yes, ideally this will be MV and MZ in one code base (lol one can dream)
Btw if you have a formation selection scene/window, that's something I can add support to my plugin. It would save me a lot of work having to actually build the scene lol

 

[gothicvoid]

add the ability to have more than 4 actors for battle. Like mine has a max of 6 on the field at any time. I have something like this already in place on mine, but i would love to see a little simpler way to utilize the feature.

 

[Tsukihime]

add the ability to have more than 4 actors for battle. Like mine has a max of 6 on the field at any time. I have something like this already in place on mine, but i would love to see a little simpler way to utilize the feature.

How does yours set up actors?

The number of actors is generally limited by MAX PARTY MEMBERS. Default battle system distinguishes between "party members" and "battle members".

In this video, I set up a single event that adds 4 additional actors on top of the one that I start with to the battlefield, using simple script calls to set positions


This is for evented "reinforcements" kind of battle. For more general cases, you would probably want to use a "battle formation" set up where you pre-define some positions that the party will try to take when they enter the battle.

 

[Solar_Flare]

Yes, ideally this will be MV and MZ in one code base (lol one can dream)
Btw if you have a formation selection scene/window, that's something I can add support to my plugin. It would save me a lot of work having to actually build the scene lol

It's basically a modification of the item select screen if I recall correctly, nothing all that fancy. I think the concept of a formation in my plugin and yours might be a little different (I didn't do a grid system or anything), but I suppose maybe the scene could be reused for yours with only minor changes...

 

[Doktor_Q]

Abilities that let you push/pull or otherwise forcibly move targets would definitely be nice. Especially, handling things like "there's another character in the way."

 

[Solar_Flare]

Or alternatively, handling multiple characters on the same space as a result of push/pull, and potentially spreading them back out to one per space when the round is over.

 

[Tsukihime]

It's basically a modification of the item select screen if I recall correctly, nothing all that fancy. I think the concept of a formation in my plugin and yours might be a little different (I didn't do a grid system or anything), but I suppose maybe the scene could be reused for yours with only minor changes...

How does your formation look like? There's two kinds of formation systems that I'm thinking of

1. Absolute position - where actor positions are defined by grid coordinates.
2. Relative position - where actor positions are relative to some point of reference (maybe the leader?)

Absolute positioning will probably be used for things like evented battles.
For general battle formations like random encounters and stuff, I think relative positioning is suitable: the formation will try to be preserved no matter where the leader is; the coordinates can be derived based on the formation details, and the leader's position.

So for example let's say you have a line formation where each actor stands in the same (vertical) row like in default RPGMaker relative to leader (A)

A
B
C
D

Or you might have a square formation.

A B
C D

I haven't figured out how I want the formation data to actually be stored, but maybe the format you designed can be used. And then I can just load up your formation information from your scene and people can plug it into their game.

Abilities that let you push/pull or otherwise forcibly move targets would definitely be nice. Especially, handling things like "there's another character in the way."

Here's a video demonstrating the use of skills to execute "move" effects.


Collision check initially will be handled by the plugin, but there are some things to consider.

For example if you push an enemy back 5 squares and there's a rock behind them, do they just smash into the rock? Or does your push skill hurl them into the air and then toss them 5 spaces away?

The actual animation might be different as well: someone that's getting knocked back in a straight line vs flying through the air. Yanfly action sequences might be able to achieve supplement the animations.

Or alternatively, handling multiple characters on the same space as a result of push/pull, and potentially spreading them back out to one per space when the round is over.

Ya, there's a lot of options. I haven't come up with a way to provide that kind of flexibility. Maybe separate "on push begin", "while being pushed" and "on push end" kind of thing? Not sure.

 

[Solar_Flare]

How does your formation look like? There's two kinds of formation systems that I'm thinking of

1. Absolute position - where actor positions are defined by grid coordinates.
2. Relative position - where actor positions are relative to some point of reference (maybe the leader?)

Like I said, there's no grid or anything. A formation is literally just a set of home locations based on actor index; if the formation has more or less than 4 coordinates, then it'll put more or fewer actors on the battlefield.

This is how I define a formation in the plugin parameters:



The minimum characters prevents the formation from being chosen if you have fewer than that many total actors in the party. Positions are just a home location and an optional auto-passive state. (I don't use Yanfly's auto-passive states; the plugin basically does its own thing to implement that.)

Absolute positioning will probably be used for things like evented battles.
For general battle formations like random encounters and stuff, I think relative positioning is suitable: the formation will try to be preserved no matter where the leader is; the coordinates can be derived based on the formation details, and the leader's position.

Relative formations aren't a bad idea, certainly! My implementation has no support for that at this time, though.

I haven't figured out how I want the formation data to actually be stored, but maybe the format you designed can be used. And then I can just load up your formation information from your scene and people can plug it into their game.

Well, it's a nice thought, but I suspect my formation data would need to be completely reworked anyway to be compatible with your system. The scene might be reusable, at least.

I guess I could just post the code so you can see for yourself whether it can be compatible... maybe later, if you're interested.

The actual animation might be different as well: someone that's getting knocked back in a straight line vs flying through the air. Yanfly action sequences might be able to achieve supplement the animations.

Just noting that I mostly avoid Yanfly's plugins for a number of reasons, so it would be nicer if they're not required at least for any common uses.

Ya, there's a lot of options. I haven't come up with a way to provide that kind of flexibility. Maybe separate "on push begin", "while being pushed" and "on push end" kind of thing? Not sure.

Hmm, I dunno. If you're talking about something similar to Yanfly's aptly-named lunatic modes, then I'm personally against it (but don't let that stop you if other people like it!). I just don't like the idea of writing code into the note box. A few simple formulas is fine, but not procedural code.

 

[Tsukihime]

1. Like I said, there's no grid or anything. A formation is literally just a set of home locations based on actor index; if the formation has more or less than 4 coordinates, then it'll put more or fewer actors on the battlefield.

This is how I define a formation in the plugin parameters:

View attachment 153701

The minimum characters prevents the formation from being chosen if you have fewer than that many total actors in the party. Positions are just a home location and an optional auto-passive state. (I don't use Yanfly's auto-passive states; the plugin basically does its own thing to implement that.)

Well, it's a nice thought, but I suspect my formation data would need to be completely reworked anyway to be compatible with your system. The scene might be reusable, at least.

I guess I could just post the code so you can see for yourself whether it can be compatible... maybe later, if you're interested.

I think I have an idea what the plugin does. So it's basically a home-position changer, where you can define custom formations (eg: diamond), assign it some coordinates, and then in the scene it'll display the formations by name so that the player can choose.

What could be done is a mapping of sorts from screen coordinates to tile.
For example, given the following grid, I've enabled debug mode so that you can see the coordinates of each tile and the tile ID.



So if you want to say a diamond at tiles 6, 15, 17, 26, you could say

(360,0), (288,72), (432,72), (360,144)

And then the extra patch plugin that bridges the two together will simply perform the necessary conversion from position (360, 0) to tile 6.

On the other hand, it could also be provided in tile ID's, so like [6, 15, 17, 26], which would then be converted into screen coordinates, which you could then use to display in your scene (assuming it shows a preview of how it looks)

Just noting that I mostly avoid Yanfly's plugins for a number of reasons, so it would be nicer if they're not required at least for any common uses.

The grid battle system (including all add-ons) will be standalone, so that won't be an issue. A lot of people currently use yanfly engine though, so having compatibility with it would be ideal if they decided they want to spice up their battle a bit.

Hmm, I dunno. If you're talking about something similar to Yanfly's aptly-named lunatic modes, then I'm personally against it (but don't let that stop you if other people like it!). I just don't like the idea of writing code into the note box. A few simple formulas is fine, but not procedural code.

I tried making some action sequences with yanfly's plugin but I didn't like how everything was just procedural code as you mentioned.

But I think flexibility in general can really only be achieved by letting users write their own commands.

Ideally, a GUI tool would be built on top that will generate the commands for you, and it would probably be quite a popular tool if you were able to get something like that built.

The tool could then manage the commands so you don't need to mess around with note-tags, but until such a solution is actually built, note-tags are still the easiest way to go with a domain-specific language.

 

[Solar_Flare]

Yeah, it's basically a home-position changer with a few extra features.

I'm not sure if it applies here, but might plugin parameters be able to work for some of the advanced things you're thinking of? I guess it doesn't make as much sense for things that are specific to a particular skill, although it is possible to directly reference a skill in a plugin parameter, so it might be something to consider...