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

[CombatJazz]

Would it be worth it/possible to define grid size, for example, if you were feeling Megaman Battle Network Inspired and only wanted a 3x6 grid? Or even defining grid sizes on a per-troop basis? Irregular grids, with some of the edges lopped off so it's not a rectangle, for boss battles and the like? I don't have nearly enough JS experience to meaningfully contribute but this would definitely be a plugin i would use for one of my current projects in replacement of the janky Yanfly Row setup I'm currently using.

 

[Tsukihime]

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...

Is the formation plugin in your plugins list? I took a look but didn't see anything that resembles it.

Plugin parameters I generally use for global stuff that doesn't change much. Like the ID of a switch for a particular thing.

Things that are object-specific (actor, skill, weapon, state, map, event, etc) I generally attach it to that specific object.

Things that might be shared between multiple objects (eg: a cross-shaped area of effect called "Cross") COULD be defined in plugin parameters and then referenced from multiple skills. Though at that point I'd probably just use an external file so that you can edit it in notepad or excel or something. I prefer external tools more than having to work with the plugin parameters cause personally I find it pretty clunky.

Would it be worth it/possible to define grid size, for example, if you were feeling Megaman Battle Network Inspired and only wanted a 3x6 grid? Or even defining grid sizes on a per-troop basis? Irregular grids, with some of the edges lopped off so it's not a rectangle, for boss battles and the like? I don't have nearly enough JS experience to meaningfully contribute but this would definitely be a plugin i would use for one of my current projects in replacement of the janky Yanfly Row setup I'm currently using.

Currently, the plugin let's you choose

- number of rows
- number of columns
- tile height
- tile width
- grid position on the screen

By default I use a 4x10 grid with 64x64 tiles, but you could just as easily change it to 3x6 as needed.



The grid is created during each battle, so as long as you make the appropriate script calls to set the grid properties, you can basically have custom grids for every battle.

Currently there is only support for rectangular shapes (because it's easy to do simple row X column grid generation), but for irregular shapes, it depends on what you actually want to achieve.

For example, let's say you start with your 4x10 grid, but then you decide hey you want like a huge hole in the middle of the grid.



What you probably want to do here is to just make those tiles "impassable" so that players can't walk on them, and then customize your battleback to look like the field you want.

Maybe flying monsters can still fly over the gaps, maybe they can't. This can all be controlled with "tile passability", which will be introduced in the movement system.

 

[CombatJazz]

Very nice. Consider my attention thoroughly piqued

 

[Solar_Flare]

Is the formation plugin in your plugins list? I took a look but didn't see anything that resembles it.

I was planning to release it but wanted to improve the UI first since it's bad at telegraphing. That is, there's a way to open the formation selection list, but there's nothing to indicate that that will work... kinda like how there's nothing to indicate how to switch pages in the shop status screen.

But now that this has come up, perhaps I'll post it after all...

Plugin parameters I generally use for global stuff that doesn't change much. Like the ID of a switch for a particular thing.

Things that are object-specific (actor, skill, weapon, state, map, event, etc) I generally attach it to that specific object.

Yeah, that definitely makes sense, but for attaching complex structured data to specific objects, I also think plugin parameters should be considered as a viable option. It's not as nice as putting it in the note tag, obviously. You would probably pre-parse the parameters and store the actual data with the objects for runtime to look it up.

Things that might be shared between multiple objects (eg: a cross-shaped area of effect called "Cross") COULD be defined in plugin parameters and then referenced from multiple skills. Though at that point I'd probably just use an external file so that you can edit it in notepad or excel or something. I prefer external tools more than having to work with the plugin parameters cause personally I find it pretty clunky.

I guess even the advanced plugin editor is a bit clunky to use, sure. On the other hand, using an external file can be pretty clunky too, especially if it's in JSON format. JSON makes for a terrible config file format - it's not intended to be user-editable, and it doesn't even support basic features like escape sequences. Even actual JS code would be better than JSON, since it allows for escape sequences. YAML is also not a bad choice - it's also a superset of JSON, so you could format the file like JSON but also have access to escape sequences while not allowing arbitrary code. (Or you could format according to the standard YAML style, if you prefer that.)

It does depend on what sort of data you're storing in the file, mind you. YAML, JS, or JSON are especially bad for anything with large chunks of text. But I don't imagine that would be a thing in the formation plugin...

 

[Tsukihime]

It does depend on what sort of data you're storing in the file, mind you. YAML, JS, or JSON are especially bad for anything with large chunks of text. But I don't imagine that would be a thing in the formation plugin...

I usually just do CSV. You can open it in any spreadsheet editor like MS Excel , libra (free office alternative, etc.

This is the design I'm going with to supplement battle position set up. It can be used for other types of grid input as well.

So for example here's potential input


Which gets saved as

Diamond,,1,
,2,,3
End,,4,
,,,
Square,1,,2
,,,
End,3,,4

I can then use the name and the END tag to figure out the number of rows, and then determine the number of columns based on the max column entry.

This can be used to store relative formations. You can also even use this to set up "starting enemy positions" for your battles, so if you had like 50 enemies you could just use this CSV to set it up. Actual details I haven't thought about but I think this is an "easy" format to use to start with.

The CSV would be transformed into JSON for easy access in the code.
You could have your own GUI tool export the JSON format directly. But the CSV is a good placeholder in the meantime.

 

[Solar_Flare]

I usually just do CSV. You can open it in any spreadsheet editor like MS Excel , libra (free office alternative, etc.

CSV is definitely a great choice for table-like data, such as the progression sequence for various classes. I'm less enthusiastic about the use you've described for storing formations, but, well, it could be much worse, so I think it's a format I could work with.

 

[Tsukihime]

CSV is definitely a great choice for table-like data, such as the progression sequence for various classes. I'm less enthusiastic about the use you've described for storing formations, but, well, it could be much worse, so I think it's a format I could work with.

Alternatively you could have a "formation map" set up in your database and just pull the data from that, offset based on the "leader" of the formation (event name, comment, etc)

For example, let's go with something that supports drag and drop to customize pre-set formations.

 

[Solar_Flare]

I actually really like that idea, but how exactly do you tell which events represent which formation?

 

[Tsukihime]

I actually really like that idea, but how exactly do you tell which events represent which formation?

Add something in the comment or note. It has a notebox but I've historically I've found it to be way too small if everyone starts cluttering it (or you write two notes)

I just parse the comments as note-tags



Actually this approach might solve some of my other issues regarding AOE radius, cause I needed a convenient way to say something like 100% damage to the main target, 50% damage to surrounding targets, etc.

 

[Solar_Flare]

Add something in the comment or note. It has a notebox but I've historically I've found it to be way too small if everyone starts cluttering it (or you write two notes)

I just parse the comments as note-tags

Yeah, putting note tags in comments is a good idea, the only problem is that then they're associated to the page rather than the event. (But in this use-case that doesn't matter.)

So, would you also need a tag to indicate which actor is which, or would it do something clever like matching the event image to actors in the database? (Which would only work if every actor has a unique image, but I imagine that's usually the case...)

 

[Tsukihime]

Yeah, putting note tags in comments is a good idea, the only problem is that then they're associated to the page rather than the event. (But in this use-case that doesn't matter.)

So, would you also need a tag to indicate which actor is which, or would it do something clever like matching the event image to actors in the database? (Which would only work if every actor has a unique image, but I imagine that's usually the case...)

There are many options. For matching event images, I did do something like that before and it was quite straightforward

Placeholder Graphics

This script allows you to use placeholder graphics for your events. The appropriate graphics will be chosen automatically by the engine during the game.This script is focused on actors and all

himeworks.com

The names I used were "party###" and "actor###" and was used for event graphics and message face pictures. It was designed for games where you could choose your own actors. The graphic didn't matter at all it was just for convenience.

Designation by actor ID doesn't work when the game has dynamic actors though where you could create any number of actors throughout the game (eg: pokemon), so party index is better.

I think for battle formations, all you need to use is party index, so party1 might be leader, party2 is the second person, etc. Plus devs can immediately tell which position is which index.

 

[Vis_Mage]

Just wanted to say that the system is looking really great so far! I've been hoping that a grid-like battle system would be made for MV, and really look forward to giving it a try!

 

[Tsukihime]

Some dev logs have been written in the past couple days

First, I had implemented grid selection, so you can pick a tile on the grid instead of picking actor/enemy directly. Then I added support for picking empty tiles, so you could move to an empty tile or summon a chicken on an empty tile.

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

I also implemented skill ranges, so you can limit how far you can move, or limit how far you can shoot your chickens

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

Next, I will be doing the multi grid system, which is more in-line with what RPG Maker battle system is like.

If you wanted to build final fantasy, you would create two grids and put actors on one grid and enemies on another grid. If you wanted front-row/back-row system, you would just give yourself two columns to work with (each row is a vertical column in a side-view system.

You could use multi-grid setup to implement classic Final Fantasy pincer attack as well

See the following examples:

 

[Tsukihime]

Couple updates

1. First round of public testing is available https://itch.io/t/912596/public-testing-1
This is the tests that early access patrons were able to do. It's mostly just to see if you can actually add the plugin into your game.

Next round of testing will be coming shortly and will explore new features such as two grids, skill ranges, and movement/summon skills

2. Basic two grid system seems to work. I'll be writing up a devlog for it to go over the details, but here's a video


3. I saw couple MZ games were released on tkool, so....I went and added my plugins to one of the projects. And so far, AoE works fine, grid selection works fine. I basically had to change like two names and added a rectangle. So I should be able to build the grid battle system for MV and MZ concurrently. I don't know if all of the features I've planned will be "easily" supported, but so far things are looking pretty good.

You can see some MZ videos on twitter.

 

[gothicvoid]

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.

Sorry for some reason my alerts didnt let me know you had asked a question to my post.
In my system the area the actors are in is designated by max x and min x by max y and min y. The actors are located on x, ys in that area separated by X amount of space to prevent overlap. You can only place the actors if they have the right note tag in the actor note box. Other than that... just changing out the number from 4 actors to 6.

 

[Tsukihime]

Some updates

1. I did some multi-target selection work and integrated it with the grid battle system, which allows you to use skill chaining. This may be useful if you have certain mechanics that need multiple selections and effects (like you select an enemy, then select an ally, or you select a target, and then select an empty tile, etc)


You can read the dev log here for more details

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

2. There are three general things that I'm adding to the system

- tile states: adding states to tiles, which will be applied to any battlers that are standing on the tile. Used to create buffs/debuffs (eg: ATK up, DEF down), tile ailments (eg: poison tile, regen tile). This can be used to accomplish "row bonuses" like if you stand on the front row, you get certain bonuses, and if you stand on the back row, you get other bonuses.

Here's a conceptualization of how it looks (F = front state, B = back state)



- target conditions: right now you can target anyone and anything. Want to attack an ally? No problem. Empty tile? Sure. With target conditions, you'll have control over who (or what) can get targeted

- line of sight: This is used with "skill range" plugin. Maybe some things should block your range, like maybe a boulder doesn't let you shoot through it or walk on it.

These new plugins should add some extra mechanics to your game.

Sorry for some reason my alerts didnt let me know you had asked a question to my post.
In my system the area the actors are in is designated by max x and min x by max y and min y. The actors are located on x, ys in that area separated by X amount of space to prevent overlap. You can only place the actors if they have the right note tag in the actor note box. Other than that... just changing out the number from 4 actors to 6.

Currently, default actor and enemy positions can be provided as a list of tile coordinates. You can specify unlimited number of positions as needed.

This is an example of how you can set up pre-defined grids, where you specify tile size, grid display offset, grid size, and actor/enemy positions (based on their position in the party, not the ID of the actor/enemy)

One_Grid = {
  1: {
    "tile_width" : 64,
    "tile_height": 64,
    "display_x" : 64 * 1,
    "display_y" : 64 * 2,
    "row_count" : 4,
    "column_count" : 10,
    "actors" : {
      1: [1,9],
      2: [2,10],
      3: [3,7],
      4: [4,8],
      5: [1,9],
      6: [2,9],
      7: [3,9],
      8: [4,9]
    },
    "enemies" : {
      1: [1,1],
      2: [2,1],
      3: [3,2],
      4: [4,4],
      5: [1,4],
      6: [2,3],
      7: [3,3],
      8: [4,1],
    }
  }
};

These are just "initial positions" when you choose to load up a certain grid configuration.
Other plugins may overwrite them, for example, certain evented battles may have custom actor or enemy positions.

 

[magnaangemon01]

Out of curiosity, how user and beginner friendly will this plugin be?

 

[Tsukihime]

Out of curiosity, how user and beginner friendly will this plugin be?

Should be user-friendly.
I don't know about beginner friendly, as you will need to make script calls to do a lot of things, such as adding a "move" effect to your skill like this which requires some programming knowledge

var position = b.getBattlePosition();
a.moveTo(position)

It doesn't provide a plug-n-play "move" command that other battle engines provide.

Things like area of effect, you will have note-tags for simple stuff, but for complex stuff you'll have to do a little extra work. Skill ranges will have note-tags. Target conditions will use formulas, for example.

I'll be providing demos and examples for different kinds of setups that people can take a look at to try and figure out what's going on.

 

[magnaangemon01]

Never done plugins. So exactly how do you do script calls in battles?

 

[Tsukihime]

Never done plugins. So exactly how do you do script calls in battles?

Most of it will be in skills, where you write a formula in the note-tag.
So when you perform a skill, it will perform the script calls.

"Move" command would be a script call that is executed when you select a tile to move to, for example.

You can also use troop events if you want to have certain things happen during the battle, maybe at certain turns, etc.