itch.io

Should be fine. My grid code supports MV and MZ. Scene might have to change a bit but it's just a compatibility thing.

I downloaded it and it looks like it's missing a line that tells MZ that it's compatible with MZ. The plugin should be fine with MZ though. 

Both. Game_Actor and Game_Enemy are pretty much the same in MV and MZ.

So I want to add actor inventories. But there's different kinds of implementations

• Each actor has their own inventories. There's no such thing as a shared party inventory anymore, everyone just keeps track of their own stuff, potentially with their own inventory limits, etc.
• Each actor has a "battle inventory". These are items that they bring with them into battle, but outside of battle, there's still a shared party inventory.

In both cases, actors will each have their own inventory object, just the way the scenes/windows are done may be different. I think I can just provide a base implementation, and then just see if someone can provide some custom handling.

I also want to have enemy inventories, which would basically be a battle inventory. This allows you to steal from enemies for example.

I think it would be an interesting implementation of multiple inventories. indeed, a "deck" of cards can be represented as an inventory, and therefore you could have inventories that represent

• your hand
• the main deck
• the side deck
• the extra deck
• the graveyard

If we consider each card to be an item, then various card/deck operations such as

• drawing
• discarding
• peeking at the top N cards
• shuffling

Can all be treated as various inventory operations.

Having a physical "inventory" item that is used to determine what your current deck is would also be an excellent way to handle things.

If you could event the battle logic to move cards from one inventory to another, then you'd have a lot of control over the rules of your card game.

There was the idea on reddit about "Zone of Control" which is some effect that is applied on targets based on a user.

I think this could be done with states, as long as you remember which battler applied which state. The actual effects of the state would then be determined dynamically at runtime.

The working example was, your movement range decreases when you're inside another target's zone, and depending on your stats and their stats, it would affect how much the range decreases. If movement range was calculated at runtime, and can apply the state formula (where "b" is the target that has the state, and a is the "user" that applied the state) I think that should solve the problem and would be able to generalize to many different things.

For MZ, there were issues with circular references: Actor holds a Tile object, which may reference the actor itself.

This has been fixed and will be available in the next release.

Grids are quite wow indeed

Loading from save files crashes the game. Problem is described here

https://forums.rpgmakerweb.com/index.php?threads/how-do-i-define-custom-objects-in-save-files.126201/

Tower Defense Engine

List of features that are relevant to building tower defense games.

Tactics Battle System

List of features from the main list that are relevant to building games that use tactics battle system

List of all features that I'll be building. If a feature is available, it will specify which plugin provides it.

If you'd like to request a feature, go here: https://itch.io/t/912556/feature-requests

Grid Features

• Adding a grid to the battle system
• Adding grid positions to battlers 
• Customizing the number of rows and columns on the grid
• Adding multiple grids to the battle field
• Adding states to tiles (for terrain effects)
• Connecting grids (virtually) to define distance between grids

Action Features

• Area of Effects for skills
• Customizing tile highlights for each grid
• Selecting empty tiles on the grid
• Multi-target skill selection
• Moving battlers around the grid
• Skill range line of sight for actions, based on skills, weapons, actor/enemy properties, etc.
• Line of sight obstruction to conditionally make tiles unselectable even when within range.

Battler Features

• Having "large" battlers that take up multiple tiles
• Summoning actors and enemies to the battle
• Summoning 3rd party battlers to the battle, who may be allied with the enemy, the party, or no alliance at all (can be attacked by anyone)
• Adding "direction" to battlers. Are they facing up, down, left, right?

Sprite Features

• Customizing the tile width and tile height of the grid
• Customizing screen position of the grid
• Setting sprite positions based on grid position
• Customizing sprite position within each tile

Other Features

• Loading battle grid from the map
• Adding events to battlers, that can be triggered (eg: based on skills, moving too close, etc)

Yanfly's YEP_X_StateCategories

Area of Effects from HIME_GridTargetArea were being loaded before the game objects were created, which caused issues. This will be fixed in the next release.

Ya, I'd like to hide the highlight at some point. Or provide alternatives. Right now there's really no alternative so if you just hide the highlights...how do people tell what the AoE is lol

Victor Engine Basic Module

All battlers have ID's for their sprites. Tiles need to have it included as well. Patch file has been updated to include this fix

// Victor Engine Basic module. Each sprite is identified by a unique ID
Game_TileBattler.prototype.spriteId = function() {
  return 'tile ' + String(this.getBattleNode().id);
};

You can add it manually or just grab the patch file.

I'll put together a battle summons plugin at some point. There will be three types of summons
1. actors - that you can control
2. enemies - that you must defeat
3. NPC battlers - basically anything else that might interact with battlers. Maybe some boulder in the middle of the road, or a tower that does AOE fire attack around it every turn so you should try to avoid it.

For the targeting rules, I'm planning to go with maybe a line-of-sight implementation, and then you could say

1. someone covers an entire column, which means you have to clear everything in one column first before you can make your way towards other columns. Maybe a tank that blocks all 4 rows.

2. they only cover their row, so maybe two have two tanks that each block 2 rows, and if you defeat one tank, you could then target the ones that are now exposed.

It will use the same concept as AOE region painting, and probably use the same shapes so you could basically re-use those AOE shapes for other purposes.

I'm starting work on Tile States. Will be using this topic for discussion.

The design is currently as follows

1. All tiles can have states
2. When a battler is on the tile, the state will be added to the battler. The state will continue to be added to the battler as long as it's on the tile.
3. When a battler leaves the tile, the state will still be on the battler. I think we can have states disappear immediately by using "on action end" removal timing, assuming a duration of 1. You should probably just use duration of 1 if you don't want lingering states. I will need to test this to make sure it works properly

States can be added to tiles in a variety of ways.

First, is in the grid config

GRID.addTileState("Two Grid", 1, 2, [2, 3])

This means that for config "Two Grid" grid 1, it will add state 2 to position [2, 3]
There's the option of adding it as plugin parameters.

What I'm thinking is you would basically copy the entire grid config from the GridBattle entry, paste it into GridTileStates. Then you would add tile states to each grid as needed. I will have to test if this approach works, but if it does, might be convenient.

I'd rather not add the plugin parameter directly into GridBattle.

Second way is part of your skill/item formulas. For example, if you target a tile, you could then say

b.addState(3)

Because a tile is just a battler as well.

A third way is maybe something like

BattleManager.addTileState(GRID_NAME, STATE_ID, POSITION)

If you need to dynamically add it during battle without any skills, and the grid config is no longer available. (the grid config is only loaded for the initial battle setup)

Hmm, I'll think about how the NPC objects will be created. Probably will all be treated as tile objects, some of them might perform skills, some of them just sit around doing nothing.

For grid hiding did you want it to apply to highlights as well? There's an option for hiding the grid outline.

Aside from enemies being able to automatically get area of effect with their skills (because the AoE is tied to skills), there isn't anything special for enemies specifically right now.

There's a "large enemies" plugin in the works, where you get to specify that a monster takes up multiple tiles. Maybe it takes up 2x2 or 3x3 square, or it takes up the entire battlefield, or something. Could probably be generalized to actors as well.

I did a little "map battle" concept where I pulled events on the map straight into battle, and played around with the idea of "talking" to events. So like in fire emblem where you could interact with other characters, I was thinking maybe you could "talk" to an enemy and turn them to your side.

This could potentially be done for two-grid system as well, where you basically assign events to each enemy and then somehow trigger the events.

Currently, the plugin parameters for each grid let's you choose highlight colors for tiles, based on action type.

Most  tactics games I've played, enemies don't really have synergy either. It's either 

1. They wait if you're too far, or
2. They just start moving towards you if you're out of range
3. They just start attacking you if you're in range

Nothing too special. Enemies aren't re-grouping for better heals, or re-positioning themselves to pick off actors.

So I think for AI plugins, it'd probably be ok to just start with a simple one that let's you add conditions to each action, and if it's not met, see if the next one is available.

Pretty much all of your conditions will probably be "is any target in range" so that might be provided as a "global" action condition so you don't need to write it again and again. Then you might have a condition that prioritizes weak targets, or "highest number of targets" in the case of AOE.

And then maybe we'll figure out how to create rules that will allow enemies to synergize better. Run back if they stray too far from allies, etc.

I'll see how I could combine it.

For the default battle system, it's basically the same battle system except you get positioning and AoE skill.

I don't think AI needs to be improved at this point. Maybe they might be smart and target characters that will result in the most damage, but that's not something I'm focusing on at this point.

Some AI changes will be needed for games with skill ranges and grid movement though, so that enemies can actually approach you to attack you.

Hey everyone,

It's been almost 3 weeks since I started building grid battle system which I think is sitting around too long. I'm planning to release the basic system which we'll start with

1. Grid positioning (HIME_GridBattle.js)
2. Area of Effect targeting (HIME_GridTargetArea.js)

The positioning system will allow you to set up your battler positions on the grid. You can choose to turn off grid-display positioning, so that the battlers won't be positioned on the grid as you've seen in the tests so far. How the sprites are displayed doesn't affect the grid logic: two actors that are neighbors can be on opposite sides of the screen, but on the grid they're still neighbors and will still be affected by AoE.

I believe the AoE targeting system is the first plugin that will provide immediate tangible improvements to your battle system. Grid position is required for AoE checking.

The initial release won't include the grid-based selection plugin, because grid selection requires additional scope logic for empty tiles, which at this point isn't something that's ready yet.

I'll start with these two and then see how it's received and determine what will be released afterwards. I will continue to develop additional features and mechanics for the grid battle system, and will be conducting exclusive patron tests as usual before they are released to the public, so if you want to try new features, make sure to sign up for early access! 

If you want to see if it'll be compatible with your project, grab the files from the second public test.  https://www.patreon.com/posts/40206494 and install GridCore, GridBattle, and GridTargetArea

The initial release will have a bit more things for the AoE and better set up, but the basic code will be the same.

Oh I didn't know about the Map inventory plugin! I looked at Kagedesu's video, and I think that plugin has already basically accomplished what I'm trying to do (visual chests, storage, grid inventory, etc.)

It would probably take not much work for him to just add support for custom item shapes to his plugin.

The work I did here is mostly just understanding how to work with grids cause I needed it for "large monsters" in my grid battle system, and maybe a game of Tetris, so if his plugin is good enough I'd probably just go with that one.

I haven't figured out a good way to let players customize message options. Plugin parameters can be set for default values but probably users need customization for each window

I'm opening up second round of public testing for grid battle system.

In this round, you'll have access to some implementation

1. Movement
2. Skill Ranges
3. Multiple Grids

Nothing's really finalized, but it would be good to see if there are compatibility issues.

https://www.patreon.com/posts/40206494

Yes. Currently it makes calls to "draw face" but that could be changed to "draw bust" instead.

Positioning can also be customized. Default code draws it on the left but we could intercept that and change it to the right, middle, above, below, etc.

Probably some note tag that will pull skill range based on current weapon.

So "attack" skill range is inherited from the weapon held instead of a fixed skill range or something.

Actually it would be quite similar to how the attack skill used the current weapon to decide the animation

Could be extended like that too. I just didn't want to bother with diagonals at this point lol

Actually with this grid approach, we can basically implement skill ranges for multi-grid setups.

You would just need a way to "connect" grids together, and then we'll know "distance" between different tiles on different grids.

For example, the right-most tile on G1 will be one tile away from the left-most tile on G2.

We can ignore flipping the grids around if we have a way to determine the "position" of each grid.

__ G4 __
G1 G2 G3
__ G5 __

Consider this grid layout.  If you only consider G1 and G2 (which is our two grid layout), G1 is "left" of G2. Which means if a chicken is standing on G1, then the "front" most column is on the right, while the "backmost" column is on the left.

On the other hand, if the chicken was standing on G3, then the "front" most column is on the left, and the back most columns is on the right

We don't consider the diagonal cases for now, but I think this approach should be suitable for even 4-sided attacks shown above.

Will be approaching this problem with a different solution.

Instead of having the chicken in the front "block" people in the back, we simply ask the chickens in the back if there's anyone "in front".

For a simple 2-grid setup like above, this is very simple: we just need to check if any enemies columns > target column.

However, the problem in general is we ASSUME what "front" and "back" means. Direction matters.

For simplicity, I will be adding a direction to the grid, so that the left grid is

3 2 1

While the right grid is

1 2 3

I'm not sure if this should affect tile designation though. For example, (1, 1) is normally in the top-left corner, but if we were to "flip" the grid horizontally, does that means (1, 1) is now  the top-right corner?

Something to consider. But let's think about more than just two grids. What if there are three grids? What if they are facing up and down? Perhaps it would be better to define "front" with respect to the direction of each battler?

Yanfly Engine Core. For grid selection,

1. Attack enemy, enemy dies 
2. select tile that enemy was on, enemy sprite suddenly appears again
3. Attempt to attack it, nothing happens. The enemy is still dead, just a visual bug

Issue occurs in function Sprite_Battler.prototype.updateSelectionEffect on line  2068, where it forces the target to be highlighted, which probably causes it to re-appear.

Post compatibility issues here. 

There's a patch file on the download page that you should get: https://himeworks.com/2020/08/grid-battle-engine/#patch

There's a request to make it so that in a two grid system, you can't target enemies "in the back" using melee weapons until the enemies "in the front" have been eliminated.

This sounds like a skill range thing but actually not really, because when the enemies in the front have been defeated, the melee attacks can suddenly reach the back. Perhaps this is a line-of-sight problem?

So for example, if someone's in front of you, it will block the enemies in the back. But in this case, "in front" involves checking an entire column instead of just the single tile in front of you.

It would be nice if this logic can be used even for the "basic" grid system, so that you must always target enemies in front.