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

[magnaangemon01]

@.@ Now I'm confuzzled. How do you do a script call each time you move?

 

[Tsukihime]

@.@ Now I'm confuzzled. How do you do a script call each time you move?

You can either put the formula in the damage formula (not recommended), or use this plugin

Formula Effects

All items and skills in RPG Maker come with additional "effects".Effects include gaining HP, learning a skill, gaining a buff in a parameter, or running a common event.However, what if yo

himeworks.com

Which allows you to write script calls directly in the note-box

<formula effect>
var pos = b.getBattlePosition();
a.moveTo(pos);
</formula effect>

When you use the "Move" skill, it will use the formula to move you to the new position.

 

[magnaangemon01]

So Move would be selected like a skill would be if you were attacking with it. Is this correct?

 

[Tsukihime]

So Move would be selected like a skill would be if you were attacking with it. Is this correct?

Yes. Everything is a skill in this system.

 

[winkr7]

Very interesting work here. I see you are moving swiftly along so I hope it is not too late to make a few suggestions:

While you are moving past an enemy if you are close enough trigger a strike (like trying to run around the flank but getting stopped by a melee enemy).

I noticed this in your code:

// doesn't make sense to have actors move forward when it's their turn.
Sprite_Actor.prototype.stepForward = function() {
// this.startMove(-48, 0, 12);
};

you probably want the user to be able to keep this kind of thing and Yanfly has a whole bunch of them for specific kinds of attacks you will want to keep.

I hope you will include some kind of terrain (if you are next to a bush you are harder to hit--if you are next to a rock you are higher and can shoot farther etc).

But lastly--why have a grid at all? You know where the sprites are and how big they are (width, height) so you could just manipulate x,y screen coords and test for distance to see if they can be hit. If you want state effects (like being in the back is safe) just say if x>700 etc.

Just my 2 cents.

It looks like you are doing very good work and I look forward to testing it all at some point.

yours
winkr7

 

[Tsukihime]

Very interesting work here. I see you are moving swiftly along so I hope it is not too late to make a few suggestions:

While you are moving past an enemy if you are close enough trigger a strike (like trying to run around the flank but getting stopped by a melee enemy).

I noticed this in your code:

// doesn't make sense to have actors move forward when it's their turn.
Sprite_Actor.prototype.stepForward = function() {
// this.startMove(-48, 0, 12);
};

you probably want the user to be able to keep this kind of thing and Yanfly has a whole bunch of them for specific kinds of attacks you will want to keep.

I hope you will include some kind of terrain (if you are next to a bush you are harder to hit--if you are next to a rock you are higher and can shoot farther etc).

But lastly--why have a grid at all? You know where the sprites are and how big they are (width, height) so you could just manipulate x,y screen coords and test for distance to see if they can be hit. If you want state effects (like being in the back is safe) just say if x>700 etc.

Just my 2 cents.

It looks like you are doing very good work and I look forward to testing it all at some point.

yours
winkr7

Suggestions are always welcome. There's a bunch here as well lol https://itch.io/t/912556/feature-requests

Having some sort of "interaction" between targets moving past each other would be interesting. I've been thinking about how to set up "Triggers" between battlers so maybe "walk within range" might be a trigger that will do something. Maybe execute a skill, etc.

For the sprite moving forward, ya it was mostly just a quick hack because it doesn't look that great in the beginning. Probably a better solution would be to figure out how to disable it just for when the actor is ready to input, instead of taking it out completely in case others are using it for other things.

For terrain effects, the current idea I'm going with is the "tile state" approach, where you would basically set up a "bush tile" with a state that increases the battler's evasion, or a "cliff tile" that increases your range with "ranged weapons" (wtype condition perhaps?)

For the grid, it's mostly just ease-of-use. I like to think of my battlefield as one big 4x10 grid or two 4x2 grids, and then all the sprites just go where they should. Specifying my ranges, AoE, etc in terms of tiles makes things easier for me to conceptualize. For example, I could say a bow has tile range 4, and it wouldn't matter how big the grid is, I know the tiles that I want highlighted are going to be highlighted. The sprite positions are of course calculated using position and size, but I'd rather abstract those details away when I'm setting up my actors and enemies, skills, states, etc.

 

[magnaangemon01]

How do I set up the Move skill? Or is it just putting the formula into the notes?

 

[winkr7]

One problem when getting rid of the Grid is checking for sprite overlap. The easiest hitbox is just the graphic width,height of the sprite. In order to move one battler to another location you will want to check if the destination is "empty" in some cases which means checking for overlap of all the sprites hitboxes. Runtime this is trivial for even 200 hitboxes, but I am not sure PIXI has this and writing it out would be a subroutine. IE given a rect at a location return a list of all overlapping battlers. If you intend to move the sprite and want to have it not be able to overlap while moving (except perhaps through your own battlers and perhaps flying over terrain hitboxes) you have to run the check at evenly intervals along the proposed path.

This is just an alternative to the grid, and something you might want to consider.

 

[magnaangemon01]

Huh?! I'm sorry. I'm not technologically literate so I have no idea what you just posted.

 

[winkr7]

sorry magnaangemon01. I was continuing some thoughts I had for Tsukihime. I don't know how you set up your move skill.
sorry for the confusion.
yours
winkr7

 

[Tsukihime]

How do I set up the Move skill? Or is it just putting the formula into the notes?

Are you using the Round 1 Test? Movement isn't provided there.
That functionality is added in Round 2 Test.

I will also be providing a demo that has some simple setups that people can look at.

One problem when getting rid of the Grid is checking for sprite overlap. The easiest hitbox is just the graphic width,height of the sprite. In order to move one battler to another location you will want to check if the destination is "empty" in some cases which means checking for overlap of all the sprites hitboxes. Runtime this is trivial for even 200 hitboxes, but I am not sure PIXI has this and writing it out would be a subroutine. IE given a rect at a location return a list of all overlapping battlers. If you intend to move the sprite and want to have it not be able to overlap while moving (except perhaps through your own battlers and perhaps flying over terrain hitboxes) you have to run the check at evenly intervals along the proposed path.

This is just an alternative to the grid, and something you might want to consider.

My grid is currently set up with tiles that are 64x64 pixels in dimension, but if you change it to 1x1 pixels, it'd be the same as using screen coordinates.

The grid is just a mapping from screen coords to tile coords.

"Place actor 1 at tile (10, 5)" is equivalent to saying "place actor 1 (640, 320) on the screen". "Move right 1 tile" is equivalent to saying "Move right 64 pixels"

With the caveat that you can ONLY move to destinations that are multiples of 64 pixels. Which I think makes sense: moving "half a pixel" isn't a thing either.

People could of course use a 1x1 pixel grid if they wanted to; it just means they need to do more math themselves. I'm sure there's a lot of grid-based games that don't use sprite-based collision although I haven't looked at how they implement it.

Would representing the battlefield as a grid, necessarily make sprite-based collision harder?

 

[magnaangemon01]

@Tsukihime I'm not using any tests yet. Soon I will be starting the eventing in my game, and since my mapper is using the 3D plugin, I thought the grid battle system would blend well with the maps.

 

[Tsukihime]

@Tsukihime I'm not using any tests yet. Soon I will be starting the eventing in my game, and since my mapper is using the 3D plugin, I thought the grid battle system would blend well with the maps.

The plugin adds a grid to the battle system, so it would be separate from the map. Which let's you do you regular eventing and stuff. It just changes the battle system.

I'm not too sure how I'll be doing on map battles at this point.

 

[magnaangemon01]

I'm aware of that. I'm just saying transitioning from the 3D maps to grid battles would be visually more appealing

 

[Solar_Flare]

Allowing things to happen as battlers move past each other would open up the possibility of executing attacks of opportunity, which could be cool.

 

[ShadowDragon]

I wait for a demo, but its looking pretty neat.

 

[kwanzaabot]

I'm using Fallen Angel Olivia's side battle UI.
Any word on how these two plugins will interact? I love the grid concept but I really don't want to go back to the default UI.

 

[Koa707]

I'm using Fallen Angel Olivia's side battle UI.
Any word on how these two plugins will interact? I love the grid concept but I really don't want to go back to the default UI.

I"m in the same boat. This plugin looks amazing and I have been following it's progress closely. I would LOVE for it to cooperate with the Olivia's UI too (fingers crossed).

 

[Tsukihime]

I'm using Fallen Angel Olivia's side battle UI.
Any word on how these two plugins will interact? I love the grid concept but I really don't want to go back to the default UI.

I"m in the same boat. This plugin looks amazing and I have been following it's progress closely. I would LOVE for it to cooperate with the Olivia's UI too (fingers crossed).

I'm unable to test it because I don't have a copy of it and it costs $10.
You can try the first public test to see if you can actually load it into your project and let me know how it goes, with some screenshots so I can share the results with others.

Public Testing #1 - Grid Battle System for RPGMaker community

I've unlocked the first round of testing. This let's you see if you can use the grid battle in your game, and explore some of the features like grid-based selection and cross-shaped AoE. Actually, eve

itch.io

If you can turn on all 4 plugins without it crashing it's probably a good start. My plugin doesn't touch any UI stuff, that's why it's just default UI.

Except grid selection, that's kind of UI because it changes the way target selection is done.

 

[kwanzaabot]

Yeah, I forgot they jacked up the price.
I've got the original version, from back when it was free. Never saw the need to upgrade tbh

Will test and let you know!