RMMV Synrec Live Tactical Battle (AVAILABLE)

[Synrec]

store page: https://synrec.itch.io/synrec-live-tactical-battle
Features

> Redesigned battle scene, computers don't do the fighting, your players do.

Redesigned battle scene
Players can move and attack freely, without limit and control their own 'turn' rather than have a computer calculate all that for them. This means that you, as the developer, are free to make powerful enemies with potential one-shot capacity as long as you can provide sufficient means for the player to evade them.



Evasion is no longer a calculated process with this battle system. Instead, players must physically move or even guard against these dangerous attacks.

Attacks are different. The player can use any attack or choosen skill as many times as they want so as long as they have the necessary resources for it. Do be warned, once a skill is chosen, a player is stuck with it until the gauge reaches its maximum. Skills therefore need a balance with regards to resources used and gained during a turn.

Alternative skill scene
The skill menu has been altered to use the custom skill menu present within the plugin. This menu allows players with 100's of skills to only equip a select few for battle.



This skill equip limit you may set in the plugin parameters.

Use suitable note tags and skill settings.


SYNREC’s LIVE BATTLE GRID DOCUMENTATION



Why use this battle system?

RPG Maker has a very standardized system. All the graphics have the same 'tone', the music blends the same, the systems all similar. What you have here is a unique opportunity to obtain code which not only modifies the generic battle system into something more modern.... more action oriented but to also obtain code which in essence is very open to own project modification, free UI adjustment, mix and matching of skill notetags to create completely novel attacks.

Ease of troop setup. No longer will you have to spend copius amounts of time to make each troop look unique and individualistic. The battle system automatically randomizes enemy positions at start and for important enemies, you can even fix these positions yourself.

Player barricaded by rocks.
Enemy AI has been modified and is now pathetically easy to customize. Developers no longer have need to fight with RPG Maker's default 'rating' system to determine the style of action an enemy will be going to take. Instead, a simple around has been taken. The enemy will use skills in accordance as to how they are in the action patterns setting. Provided the set conditions are met.



Taking this a step further, you can even tag enemies with <noDupeAction> to prevent an enemy from essentially spamming a skill.

Customize action patterns and combine them with note tags to create enemies whose patterns are in full control or, take it a step further with the random AI action which has a 4/6 chance to move 1/6 chance to use an action and 1/6 chance to guard.

Beams pierce block projectiles, reducing their hit count. Grenades can bypass them.

 

[pasunna]

but... does it real time or turn base
the strong point of that system is fast pace

 

[Synrec]

but... does it real time or turn base
the strong point of that system is fast pace

It's both.

Turn based because of the gauge, real time because while the gauge is filling (and even if full) actions happen freely.

 

[Lay]

Wow, great job.

I can't imagine the work it requires to implement such a thing over the default rmmv engine.

btw, I'm a bit confused about the name you gave to this thread and what the plugin does. It seems that this plugin is more likely a battle system plugin, in this case a tactical battle system. Grid battle makes me think more about a targeting system (something similar to yanfly row formation per example).

Curious to see how this plugin will evolved ! you're great.

Lay.

 

[Synrec]

Wow, great job.

I can't imagine the work it requires to implement such a thing over the default rmmv engine.

btw, I'm a bit confused about the name you gave to this thread and what the plugin does. It seems that this plugin is more likely a battle system plugin, in this case a tactical battle system. Grid battle makes me think more about a targeting system (something similar to yanfly row formation per example).

Curious to see how this plugin will evolved ! you're great.

Lay.

It's not really a select your enemy type of system, it's a projectile grid system similar to Megaman battle network.

Thanks for the well wishes on the other hand. Even with this post, I still can't really see the end point as being near haha...

 

[Synrec]

Development of this script has been paused for 2 reasons.
1) RPG Maker MZ? Is going to be released and I figure developing for that platform would be better.

2) My comp basically crashed and whilst I do have a back up, the backup is rather out dated.

Anyways, see you all for MZ

 

[ShadowDragon]

I dont take MZ, but I hope you get this plugin done for MV though, or at least in a function state.
it looks pretty nice though, specially if you can input the grid, 3x3, 4x4, 4x3
or to a max of 5x5? or similair. nicely done though =)

 

[Synrec]

I dont take MZ, but I hope you get this plugin done for MV though, or at least in a function state.
it looks pretty nice though, specially if you can input the grid, 3x3, 4x4, 4x3
or to a max of 5x5? or similair. nicely done though =)

Was going to redo the whole thing given that it's pretty outdated and my experience with code was new when I started this so yeah, I'll see if I can give it a shot. No guarantees tho because tbh, you can't use MV or from what I'm seeing of MZ, the native constructed battle system and I'd have to scrap the whole native battle system and reconstruct the elements

If the core scripts are similar enough, because it doesn't look that different, it should be cross compatible with minor edits

 

[Synrec]

Well, here's a long over due update.

1) Rudimentary collision system implemented. It's still a work in progress because i need to work out how to interpret each sprite object in the battle scene.

2) Framework for battle skills implemented. A work in progress still as i have to now redesign the windows and possibly delete a few to prevent clutter. Developers can define a maximum for how many skills can be equipped but the inventory length is the length of the database skill list.

3) Side view enemies implemented. Battle enemies have their own motions. Enemy movement patterns are still a work in progress and i may have to reference other scripts to allow developers to write code within enemy notetag box. Or I can forgo that and simply write an extension script that allows players to write movement paths from the plugin editor. This is still under consideration.

4) By request, I have moved the player to the left side of the screen. Be that as it may, the developers can still decide to have the players on the right side of the screen but with this re-write of this script, this is a work in progress.

5) No plugin editor code has been written as yet to bolster development speed of the script. While this isnt an issue on its own, it indicates that so far this script is looking at over 3~4k lines.

6) I have been asked if this is turn based or if enemies and players move automatically with skill input. It is not. This is a sprite based system and as such, almost all factors of this combat system are player dependent after initial development. I still have to work on the implementation of skill formulae as well as rework EX and SP parameters so these are a while off.

7) It is possible to change battle arena size between 3*6, 4*8 and 5*10. Arena size influences the max number of enemies. There are bugs to work out regarding this.

8) Framework for battle arena size change (area steal) and grid effects implemented. Code is inert as there are still a good bit of functions to be written.

9) Multiple actor game party is not implemented. Not even the framework for it exists yet. The problem isn't the possibility, it is the fact that a gross amount of new functions need to be written.

10) Overall, my main concerns will be the collision system and how it functions under pressure (or bullet hell).

Well, ill try to upload some screenshots later but for now, this is it.

This script is no where near completion as of now but when it is, depending on how MZ works, it should be possible to cross implement it. Haven't gotten around to ordering it yet....

Any questions and concerns?

 

[so1us]

This plugin looks super interesting! Looks like a very difficult feature set to pull off in RPG Maker the realtime component but if it works it would be a great addition to the combat possibilities in RM!

Will follow the development and best of luck!

 

[ShadowDragon]

I hope you can aim for MV first, so far I know, MV and MZ javascript wont work though,
if you build it in ES5, MZ only use ES6, but can be ES5 compitable.

MV and MZ cant be cross though, it require a different coding for MZ,
so I hope you get it done for MV and check later if you want to port it to MZ.

 

[Synrec]

I hope you can aim for MV first, so far I know, MV and MZ javascript wont work though,
if you build it in ES5, MZ only use ES6, but can be ES5 compitable.

MV and MZ cant be cross though, it require a different coding for MZ,
so I hope you get it done for MV and check later if you want to port it to MZ.

Definitely doing MV first so no worries.

Doing a port has checks which need consideration.

 

[Synrec]

Latest Devlog


So far I have not posted a 'True' development Log with regards to this script.

The Synrec Grid Battle Library is a live action battle script that changes the fundamental properties of RPG Maker's turn based battle system. No longer would players be constrained to only performing a single action per turn. No longer would attacks missing be depended on random calculation by the game's engine. No, what this plugin does is transform the combat from RNG based to Skill based.

Features (Player Focussed)

• Optimization for solo style combat: Only one actor is controlled at any given time however, players can use the Party option during battle scene to swap actors.
• Grid style movement: Players can move on a grid to dodge or line-up attacks. Enemies may also do the same.
• Skill Equip Scene: A scene where even if the player knows 100's of skills, they may only equip a set number at any particular time to use in battle.
• Skill Use: Skills may only be used once in battle before they are made unavailable for the battle.
• Guard Made useful: Players can opt to guard against an attack which checks the appropriate parameter against the skill's power.
• Anti-skill spam protection: Players cannot simply run through their entire skill deck. A battle gauge has been implemented to regulate the access to the skill selection screen.

Features (Developer)

• Unique skill color font based on hexadecimal code.
• Designation of pixel type or teleportation type movement per actor.
• Ease of power balancing, no complex formulae to calculate, player skill determines whether damage is effected or not.
• Rating system so that you can add rating towards how powerful a skill is.
• Custom Icons for Player HP, MP and TP.
• Custom Gauge Color for Player HP, MP and TP.
• Ease of coloration of player and enemy grid via hue modification.
• =More to be added as development progresses=

________________________________________________________________________________________

Some screen shots of what has been completed so far.

Design of player and enemy grid. Enemies can adopt side-view actors but this is a work in progress.

(Top-Left) The player Status window which displays the value, Icon and gauge of HP, MP and TP. The box below is for player status Icons but most likely this left side of the screen will be modified to account for multiple actors in Player Party. The window showing "No Skill Data" shows information on selected skills.

(Top-Center) The Battle Gauge which regulates access to the skill selection screen.

You may notice that the endges of the screen have the battle back looking a bit funny. This is due to bad sizing of the battle background and the game's resolution.

This is the skill Equip scene.

(Top-Left)The list of skills equipped by that particular actor. To add would be a small window which shows how many skills that actor has equipped VS their max. May add skill resource costs later.

(Bottom) Is the skill Inventory. It only displays the skill name from the pool of skills the actor has acquired in the game. All skills are saved as objects rather than as only their ID so that individual modification to each skill can be made later on. These future modifications can include but is most definitely not limited to: Skill Leveling, Multiple instances of Skills, Skill Editing, Skill Evolution. The icon appearing before the skill name is used to indicate whether or not a skill is equipped.

(Top-Right)The skill data. What it displays is the skill name and icon, the element (if any), The skill effect (HP Damage, MP Drain, etc), resource costs and the skill power. Currently I am working on an intuitive way of making use of RPG Maker's formulae shortcuts such as 'a.atk' for those comfortable with using RPG Maker's default formulae.

______________________________________________________________________________________

That's it for this update. The next update is definitely not any time soon but you are free to ask questions and I will respond to the best of my ability.

Ciao!~

Synrec

 

[Synrec]

Just posting what I mean by live grid battle system.

This is in no way shape or form a 'select your enemy' or 'select grid area' kind of script.

The closest system to this is megaman battle network and maybe pokemon once I finish making modifications to how game party works in this engine.

I don't think this will be finished any time soon.

 

[Synrec]

Hey everyone, just an update.


In this post, we will be discussing the two most important features of the live grid battle script, projectiles and enemy movement. Before that, a re-cap to the last development log spoke about skill equip and selection, so far, those parts of the script are still in development. Whilst due to the projectile system, it is now possible to choose and make custom projectile skills with their own custom bitmaps.

Projectile bitmaps use their own folder for ease of project management. I have considered appending animations to projectiles for lessening of data load for game projects but this won't be implemented any time soon as I still have to implement these parts of the projectile system:

• Area Scopes (Currently, projectile hit area is only the impacted target.
• Projectile move paths (Currently only travels in a straight line).
• Appending elemental effects (Currently, RPG Maker's build in element system is... abysmal. I am currently working on a way to see how to get this working with the now live battle grid.)

Although this is short, getting a working projectile system in RPG Maker means that it had to be coded up from scratch but with this, the path is paved for ideas such as:

• Elemental Projectiles (Can change color of projectile image via hue so as to reduce data load.)
• Obstacles and specific grid effects. (So that players (or even enemies) can place obstacles or the field can induce status effects on the player.
• Field projectiles (For game projectiles like a battle under a meteor shower for example.)

For now, the next stages would be to refine all the current framework that are in place into something more solid before moving onto adding new ideas.

Thanks for reading, do have an awesome day!

 

[so1us]

Looks really neat and smooth. Can't believe you're actually getting this done in RPG Maker.

Does the number of projectiles on screen at once impact performance much?

 

[Synrec]

Looks really neat and smooth. Can't believe you're actually getting this done in RPG Maker.

Does the number of projectiles on screen at once impact performance much?

I'm inclined to say no given that it doesn't appear to lag on the FPS even with 100+ on screen but a more solid answer can come after I load scopes and enemy attacks.

 

[so1us]

Glad to hear it. Constantly surprised with what ppl are able to do in RPG Maker. Looking forward to your next update!

 

[Synrec]

Documentation

SYNREC’s LIVE BATTLE GRID DOCUMENTATION

SECTION A – PLUGIN MANAGER SETTINGS

May be used to set project resolution, modify battle scene UI, establish default grid settings, establish default anchors, setup default attack skill ID and default guard state. Set default move types and move speed.

Particular attention must be paid towards Field Setup.

> [Battle Arena offset – X] determines the starting X-coordinate of the battle arena.

> [Battle Arena offset – Y] determines the starting Y-coordinate of the battle arena.

> [Arena Grid Width] is the width of the individual grid and also determines determines the width of the hit box.

> [Arena Grid Height] is the height of the individual grid and also determines the height of the hit box.

> [Player Grid Hue] is the default hue of the battle grid.

> [Enemy Grid Hue] is the default hue of the battle grid.

> [Battle Arena Size] is the default field size designated to actor/enemy, eg: 3 means a 3x3 field size for either actor/enemy.

> [Player Arena Position] determines which side of the screen the player occupies. Currently as of the ALPHA version, only the left side is functional. Using ‘right’ will result in crashes and experimental behavior.

NOTE: Provided with the plugin will be a battle grid which can be freely modified by the developer. The plugin is setup for this battle grid by default.

Battle General Settings may require some attention but is not particularly important for the setup of the plugin.

> [Default Attack Skill] Skill ID of the default attack skill.

> [Default Guard State] State that is added when guarding. Please note: The special flag guard in the state traits is NOT used for guard calculations.

> [Default Player Move Type] Default move type for actor sprites. Options are pixel and teleport.

> [Default Enemy Move Type] Default move type for enemy sprites. Options are pixel and teleport.

> [Default Pixel Move Speed] Default move speed for pixel movement. Teleport movement type and delay is always 0.

Participant anchor setup is used to determine the default graphical anchor for actor and enemy sprites. This is an ‘offset’ of sorts.

Player Battle Status affects the player mini status window shown in battle scene.

Provided it has not been modified in the plugin parameters, this is the player battle status window which appears on the top-left of the battle scene.

Enemy Window shows the enemy Name, HP, MP and TP Status during battle. Customizable are the gradient which acts as a block background and text font colors.

The enemy window displays the alive members of the game troop only and when an enemy dies, it automatically updates by removing dead enemy data.

The block gradient may be either vertical or horizontal.

All colors use Hex Codes. Eg: #FF00BB

Run Window settings setup the default parameters for escape. The process for escaping is NOT random. Players have to repeated push a button (currently as of Alpha Version, the confirm button), to build up an escape gauge against the enemy.

Battle Gauge Settings establish base parameters for the Game’s Battle Gauge. This includes text which displays when the battle gauge is filled.

Window Settings allow for customization of various windows in the battle scene and in the skill equip scene.

SECTION B – NOTE TAGS

Following is a list of functional tags.

[Actor Tags List]

<moveTypeixel>

Sets move type for that actor to pixel.

<moveType:teleport>

Sets move type for that actor to teleport.

<floating>

Allows the actor to ignore hole obstacles.

[Skill Tags List]

<fontColor:x>

x = hex color code, eg: #ff00bb

<rating:x>

x = rating value.

<bitmap:x>

x = name of projectile/obstacle bitmap.

<bitmapAx:x>

x = X-anchor of projectile/obstacle bitmap.

<bitmapAy:x>

x = Y-anchor of projectile/obstacle bitmap.

<bitmapHue:x>

x = hue of projectile/ostacle bitmap.

<actionMotion:x>

x = name of motion performed when using skill, eg:{Chant, Guard, Damage, Evade, Thrust, Swing, Missile, Item, Escape, Victory, Dead}

<duration:x>

duration, lifespan of projectile. x = frames. Not applied for obstacles.

<attackDuration:x>

attack duration, skill re-use delay time. x = frames.

<hitArea:x>

x = area spread of attack from origin when target is hit.

<hitCount:x>

Beam only, max number of hits before projectile is destroyed.

<hitDelay:x>

Beam only, delay time in frames between hits.

<areaType:cross>

damage area in a {+} type.

<areaType:square>

damage area in a {[ ]} type.

<range:x>

x = horizontal range of the projectile.

<projectilePath:bullet>

projectile is destroyed on impact.

<projectilePath:grenade>

projectile is thrown to target range.

<projectilePath:beam>

projectile is only destroyed when range is achieved.

<explode:x>

explode creates child projectiles in hit area, x = animation ID.

<explodeHit:x>

x = animation ID played when child projectile collision occurs.

<addState:x>

x = ID of state to be added.

<obstacle:x>

defines skill as an obstacle spawner. x = durability. ObstacleType must be defined.

<obstacleType:block>

creates a permanent obstacle which is only removed by projectiles.

<obstacleType:hole>

creates a temporary hole obstacle which lasts its durability + 100 frames.



Skill DataBase:

1: General Settings. Name and description text color may be changed by using <fontColor> note tag. Scope must be set to user for skills to be used on self.

2: Damage settings. The nature of damage calculation has changed. DEF and MDF are only applied when guarding and define the maximum amount of damage that can be absorbed whilst guarding. As a result of this, the ‘b’ tag used to define target parameters has been changed to take either the game party or game troop value.

3: Effects are not used.

4: Invocation is extremely important to setup. More particularly, the speed which defines projectile move speed. This is not important for obstacles.

5: Notetag area. You place note tags here.

[Weapons Tags List]

<skill:x> : x = attack skill ID.

[Enemies Tags List

<bitmap:x> x = sv_actor image to use for enemy bitmap.

<moveDelay:x> : x = time in frames between actions.

<moveTypeixel> : sets enemy move type to pixel.

<moveType:teleport> : sets enemy move type to teleport.

<floating> : Allows enemy to ignore hole obstacles.

<weaponId:x> : x = weapon ID used for undefined action motion.

<AI>up, down, forward, backward, useAction, Guard, Random</AI> : Available commands for directing enemy AI.

<noDupeAction> : Prevents use of same action twice in a row.

<spawnX:x> : x = X-coordinate for enemy spawn.

<spawnY:x> : x = Y-coordinate for enemy spawn.

*The action used when useAction is called is determined by action pattern settings. The skill priority order is as it is listed in the action patterns and as such, the random factor from ‘rating’ is not used. This allows for the developer to easily setup and balance enemies.

*Fixed spawn setting is randomized if two enemies occupy the same location.

[States Tags List]

<svOverAnim:x> : Animation that plays on the layer above the battler sprite. x = animation ID.

<svUnderAnim:x> : Animation that plays on the layer below the battler sprite. x = animation ID.

<floating> : Allows state holder to ignore hole obstacles.

*States have a refresh tick of 300 frames.

*Traits, Only Param: All parameters may be used, only regenerative EX parameters may be used.

[Map Tags List]

<playerGrid:x> : x = Name of grid bitmap to use for the player.

<playerGridHue:x> : x = Hue of player Grid.

<enemyGrid:x> : x = Name of grid bitmap to use for enemy.

<enemyGridHue:x> : x = Hue of enemy Grid.

 

[so1us]

oh boy that looks comprehensive!
Are you happy with the progress you've made so far and any areas that are causing more issues than they should?