Battlesystem for Avarion-Games

[Andar]

I'm currently in the first stages of designing what I want to use as a battlesystem for my games.
It'll probably be a few month before I will look for a scripter to help with those parts that I can't do myself, but until then I would like some opinions about the ideas.

Especially I would like to get some scripter's opinion whether it would be easier to piece the parts together from existing scripts and add compatibility patches, or if it would be easier to make it a completely new and independent battlescript.
The reason for this is that I want to exchange several of the basic elements of the default engine, and going in and out of the default API might cause more problems than disabling default battle and designing something completely new - but I don't have enough specific experience with RGSS3 to quantify that suspection.


Overview of changes/ideas:
1) Pre-Battle processor/wrapper
2) Completely exchange HIT%/EVA% and Damage processing
3) four energy scales (LP/EP/SP/MP) instead of HP/MP/TP
4) ATB/CTB-Variant Battlescript
5) targeting options, attack patterns and AI
6) Front-view HUP with pictures for the actors (either busts or battlers, NOT faces)

Details:

1) Pre-Battle processor/wrapper
No matter how a battle is called (event command or random encounter), instead of going to the battlescreen this part of the script is called. It then processes the following steps:

Step 1: check troop for prebattle-event
If the troop contains a troop event marked as pre-battle, that event is processed first (no display!)
Basically this is to randomize the troop by appearing or transforming some of the enemies in that troop, but optionally other event commands or scripts for special enemies/logistics/quests would also be nice, as well as the option of calling a common event from this troop event.

Step 2: calculate and compare troop and party strength
Most probably by checking notetags on the enemies that exist after step 1, a total battlestrength of the troop is estimated and a similiar value calculated for the party as well.
Depending on the results the preprocessor script reacts differently in step 3.

Step 3: choosing battle
For "real" battles with stronger or equal enemies, the battlescript is called. For "lower" enemies there will only be a message "you encountered XY. Z damage received, loot gained" - or perhaps a call to a common event to give more options for the battleresults.

Basically a way to disable booring low-level enemies for high-level parties

Step 4: After-Battle checks - optional
Perhaps calling a common event with special data after each battle - not yet decided as I don't know if I need that

Tsukihime has a few scripts that might be modified for this, but most probably it'll need a new script. To be decided later


2) Completely exchange HIT%/EVA% and Damage processing
In most JRPG (and in the default Ace engine) the actor and enemies scale along damage, and HIT% is intentionally extremely high (and thereby not a usefull deciding number) while EVA% remains low.

Also see http://forums.rpgmakerweb.com/index.php?/topic/4219-rpg-maker-vxace-damage-flow/
As a result, fighting a higher enemy will show less damage done by the actor while higher damage is received from the enemy.

I would like to change that to an attack roll for attack quality and a similiar roll for defense quality. The scale/level would increase the values for both attack and defense, and a hit would only happen if the attack quality is higher.
As a result, fighting a stronger enemy will show a lot of misses from the actor while the enemy misses less often.

(I would create a flowchart for the new handling to help the scripter with the coding, but that are details for later)

OK, and here I need some special feedback from scripters:
I haven't seen a script that tries to change that basic part of the engine's damage flow. But I do not know if that is because no one had such an idea for it before, or because changes there are extremely difficult (in that case I'll have to rethink my options)

Also, what would players say to such a difference? It goes away from the JRPG-default of RM and approaches the game mechanics of western RPGs, especially PnP-RPG's. Would players see that as a refreshing change or as a disturbing need to learn a new way to estimate battles?


3) Four energy scales (LP/EP/SP/MP) instead of HP/MP/TP
MP and EP (endurance points) would be similiar to current MP/TP.
LP (life points) would be the same as HP, with LP=0 resulting in death state
SP (stability points or soul points) would be new, with SP=0 resulting in coma state

Death and Coma would be equal states, not affecting each other, and death would no longer remove all other states but only physical damage states, while Coma would remove all mental damage states. Both would require different, specific skills to remove the state.

In the editor skills can either be physical attack or magical attack, and the damage formula can either be targeted on HP or on MP.
Since the damage flow will be rewritten (see 2 above), I would use those settings for damage selection instead of working with tags:

If the skill is set to physical attack, HP setting will damage the lifepoints and MP setting will damage the endurance (HP/TP).

If the skill is set to magical attack, HP setting will damage stability points and MP setting will damage MP (SP/MP).

In the case that I have to forgo such a replacement for damage processing, I would need notetags for the other damage settings (SP-Damage, TP-Damage), but if possible the handling of the attack type and damage type combined would be easier for game development than using notetags...

There are some scripts that change TP-handlings, but none that introduce a fourth number or a new state equal to death.
Additionally there is no HUD for that in any existing battlescript - which means either a heavy modification of an existing script or a completely new script for the battledisplay

What are your opinions on this option? I would really like to use it, and it should not add too much if the damage flow can be rewritten - but if that is not rewritten and the battlesystem is combined from existing scripts, I might drop this part unless a lot of people find it interesting


4) ATB/CTB-Variant Battlescript
There are several CTB and/or ATB scripts already available and I could easily choose one of them - in fact I originally planned to do that. However, including 2) and 3) into an existing ATB-Script would require a lot of familiarity of the scripter with the ATB, and it might still be a lot of work. And possibly it's less work to code a new ATB directly with those two points in mind.

And designing a new ATB would allow me to change additional minor aspects compared to the existing ATBs, like using a dropping delay scale instead of a rising power scale for the time measurements.

This is basically the key to the decision whether to write an entirely new battlescript or to use several existing battlescripts and only write add-ons/compatibility patches, and I would like to hear opinions from experienced scripters of what they would do in such a case.

The changes in the damage flow are important to me and I would like to know if they would be easy to add to an ATB, or if it would be easier to write a new one for them.


5) targeting options, attack patterns and AI
The current enemy AI isn't exactly the optimum in selecting which skills to use, and the changes above will probably ruin what's left of it.
However, there are several scripts available to replace or improve the attack patterns, and I'll have to decide if I use one of those or have a new one written as part of a new battlescript.

Comments and ideas of what should be included in such a case are welcome, but don't bother looking for or linking existing targeting and AI-scripts. For compatibility reasons that can't be decided until the other parts above are more finished, and I probably know more about AI-logic and AI-design than 95% of the others here.


6) Front-view HUP with pictures for the actors (either busts or battlers, NOT faces)
That would still have to be designed and I would prefer to have it done with or compatible with the LUNA engine.
It will be done last and I only place this info here as a reminder not to forget it.


Additional comments:
I'm a professional programmer (equivalent of master's degree in computer sciences), but have zero experience with Ruby and it's been a while since I last coded in other languages. So I have no problem in providing a scripter with flowcharts for coding, and testing (including repairing code) everything myself. I just don't know where to even start replacing the default scripts, so the coding itself will require a lot of help (probably by a classified commission later).

In this topic I don't want any finished code or similiar results, I want comments to help me decide what is realistically doable in the later coding stage and to prevent me from making too many mistakes in the design of the flowcharts and data structures.

 

[bgillisp]

For #2 I think you could do it with a rewrite of Item_apply, as that seems to be where all of that occurs. In my game I rewrote it to do item_hit - item_eva (this is not the exact code, but the idea of the code), then decide if it is a miss if a random number between 1 and 100 is greater than that number. For example, if you used the default of 95% to hit and 5% eva, this would mean you get a hit if the random number is 90 or less (95 - 5), and you miss if the random number is 91 or more.

I also had to remove evading completely to do this, as I decided to have only misses, no miss and evade.

I think you could do your idea in that same area of the code. I've even thought of changing it so that a miss is not 0 damage, but a weak hit (partial damage), maybe dependent on how badly you miss?

 

[♥SOURCE♥]

Especially I would like to get some scripter's opinion whether it would be easier to piece the parts together from existing scripts and add compatibility patches, or if it would be easier to make it a completely new and independent battlescript.

It would be easier to make it a completely new and independent script. It would also be more stable, easier to maintain, and easier to expand.

 

[Engr. Adiktuzmiko]

I want comments to help me decide what is realistically doable in the later coding stage and to prevent me from making too many mistakes in the design of the flowcharts and data structures.

As someone who's making his own battle system from scratch, I say all those are highly doable. And I agree with SOURCE, I have tried editing the default system before but it was quite hard, while doing it from scratch was easier. It was also more fun, learning how to implement exactly what you like.

 

[Sarlecc]

So with number 5 you could have something like a series of checks based off: states, the player's current health, is the player buffed, AI's current health etc to decide what the AI will use on said turn based on skills it has access too?

Like for example AI has a cure skill and a debuff player skill.

AI is poisoned and there is no buff on the player.

So it would make more sense for the AI to cure it's self vs even trying to use debuff.

But lets say that the player's current health is low enough for that player to be knocked out in one more hit.

Instead of the AI using cure it uses it's normal attack to try and knock out the player.

Basically an AI that uses logic vs pseudo-randomness or turn used based attacks.

(Think the above would cover AI and attack patterns possibly even some targeting options)

For targeting options maybe something like attack last/first target who attacked the user?

Target strongest, Target weakest, Target most buffed, Target least buffed, Target by ID, Target with most skills, Target with least skills, Target any who has say a certain word/character in their name defined by the developer.

 

[DoubleX]

After reading all the 6 points, if a script does focus on exactly 1 of them and has excellent compatibility and modularity, it won't even touch the "how" part of any other of those points at all, meaning complete separation of concerns among all those 6 points is possible, although extremely challenging.

For example:

Pre-Battle processor/wrapper deals with stuffs right before starting a battle, while all the others deal with stuffs during battles, meaning their working time are completely separated.

Completely exchange HIT%/EVA% and Damage processing and Four energy scales (LP/EP/SP/MP) instead of HP/MP/TP don't need to know how each other work, although the former might need to know the presence of SP.

ATB/CTB-Variant Battlescript deals with the battle turn, and action input(including inputability check) and execution mechanics. It doesn't need to care about damage processing nor energy scales.

targeting options, attack patterns and AI deals with what action and action targets are valid, and how to pick actions and targets among all valid ones. If those options are setup by script users using RGSS3 codes, this point doesn't need to care about how any other point works, although you'll have to teach users how to setup properly.

Front-view HUP with pictures for the actors (either busts or battlers, NOT faces) deals with battle visuals, while all the other points deal with battle mechanics, meaning they don't have to know how each other works, although the former needs to know the presence of atb bars or the ctb action order queue.

Therefore, I'd recommend using each separate(although not necessary standalone) complete script for each of those 6 points, instead of dealing them all in a single script. Again, those scripts need to have excellent compatibility and modularity in order to work altogether.

About the relations between those 6 points, I'd see something like this:

ATB/CTB-Variant Battlescript will be the central hub. Everything else(except Completely exchange HIT%/EVA% and Damage processing) will be connected to it. Think about the star network topology.

Pre-Battle processor/wrapper will be connected to ATB/CTB-Variant Battlescript for battle initializations, via passing the battle start information from the former to the latter.

Completely exchange HIT%/EVA% and Damage processing will be connected to Four energy scales (LP/EP/SP/MP) instead of HP/MP/TP via damage applications to those energy scales.

Four energy scales (LP/EP/SP/MP) instead of HP/MP/TP will be connected to ATB/CTB-Variant Battlescript via knockouts(clearing the atb bar or getting out of the ctb action order queue), battler inputability checks(if at least 1 actions are usable), etc.

targeting options, attack patterns and AI will be connected to ATB/CTB-Variant Battlescript via using ATB/CTB specifics, like ATB refill percents and speeds, or the atb action order queue positions, etc, to form the AI decision algorithms.

Front-view HUP with pictures for the actors (either busts or battlers, NOT faces) will be connection to ATB/CTB-Variant Battlescript via displaying the atb bars or the ctb action order queue.

For this reason, I'd recommend writing a script for ATB/CTB-Variant Battlescript first, although that script needs to be compatible with all the other points(meaning it needs to have excellent compatibility and modularity).

About the implementation difficulty, it greatly depends on the degree of control and freedom you wish to give to your users. In general, the greater that amount, the higher the difficulty.

If the user control and freedom always stays at the bare minimum(hardcoded whenever possible), I'd expect the prerequisites as having some battle related scripting proficiency(inexperienced scripters having written few simple yet complete battle related scripts, and basic knowledge of how the battle related parts of the default RMVXA scripts work).

If the user control and freedom can reach the "RGSS3 codes, which can be edited on the fly, as configuration values" level, I'd expect the prerequisites as having advanced battle related scripting proficiency(scripting veterans having written at least 1 advanced complex battle system, and a thorough comprehension of how the battle related parts of the default RMVXA scripts work).

The below are 2 posts that might help this request:

http://forums.rpgmakerweb.com/index.php?/topic/39173-how-to-write-an-atb-system-script/

http://forums.rpgmakerweb.com/index.php?/topic/39139-deciding-the-degree-of-control-and-freedom-given-to-script-users/

 

[Engr. Adiktuzmiko]

So with number 5 you could have something like a series of checks based off: states, the player's current health, is the player buffed, AI's current health etc to decide what the AI will use on said turn based on skills it has access too?

Like for example AI has a cure skill and a debuff player skill.

AI is poisoned and there is no buff on the player.

So it would make more sense for the AI to cure it's self vs even trying to use debuff.

But lets say that the player's current health is low enough for that player to be knocked out in one more hit.

Instead of the AI using cure it uses it's normal attack to try and knock out the player.

Basically an AI that uses logic vs pseudo-randomness or turn used based attacks.

(Think the above would cover AI and attack patterns possibly even some targeting options)

For targeting options maybe something like attack last/first target who attacked the user?

Target strongest, Target weakest, Target most buffed, Target least buffed, Target by ID, Target with most skills, Target with least skills, Target any who has say a certain word/character in their name defined by the developer.

basically what I'm doing on my battle system... AI for each would be written in ruby methods so I could make really various behaviors... The way I did it, the skill/action would be selected first then the target. The action selected is passed into the target selection so you could tandem them up, like if one actor is below this health, then use this skill; then on target selection, if this skill is used, choose the actor with lowest health. My implementation was that you simply use notetags to denote which method to call, to minimize the amount of text on the notebox.

BTW, I presume the system is for private use on your projects?

 

[Andar]

So with number 5 you could have something like a series of checks based off: states, the player's current health, is the player buffed, AI's current health etc to decide what the AI will use on said turn based on skills it has access too?

Far too inefficient - as I said I know a bit about AI programming, and any series of checks would require too much work with too many checks to produce a halfway decent and variable AI.

Instead of this, I'll plan to segment the AI into three different parts:

1) for several reasons I need a rather complex target manager, something like Enelvon's http://forums.rpgmakerweb.com/index.php?/topic/30722-target-manager-v10-initial-release/

In fact Enelvon wrote that one after a PM discussion where I gave the idea.

That target manager would allow the creating of things like healing skills that only work on allies with low HP (or finishing skills for enemies with low HP) and so on.

That will completely take care of the AI targeting problems - if several enemies have low HP, it doesn't matter which one is healed but the action would not be wasted on an unharmed enemy.

2) there will be a number of "AI states" like "defensive", "offensive" or "suicidal" that will be assigned based on battleconditions

This will still require some thoughts, especially which part of those states are scripted in the engine and which ones are handled otherwise (perhaps with a followup-state-script).

3) with 1&2 in place, I can simply use the regular attack patterns to program an enemies individual AI, like when a healing skill is conditioned on the defensive state and so on.

That way I could do a lot of AI decisions without bothering with the work of a scripted AI and dozens of value checks like Engr. Adiktuzmiko says above as well.

BTW, I presume the system is for private use on your projects?

No final decision, but probably. I'll start with keeping the details for my own project(s) and will later decide if I keep it mine, give it to certain persons only or release it publically.

Will also depend on whether I'll have to pay a scripter for the more difficult parts or if it could be done without paid commissions.

 

[Engr. Adiktuzmiko]

well yeah that could be pretty long depending on the AI, but I prefer it that way as from past experience when I try to "simplify" things, I also end up causing limitations to what it could do... XD

Anyway, I guess that still depends on how vast the possibilities and how much you could simplify. I'd surely be looking forward to the progress of this idea as it's one of the things that I think aren't focused much when it comes to the development of RM games.

 

[Andar]

Given the answers so far, and due to some more research on my own, the system will be completely independent of the existing battlescripts.


This will also allow me to add some changes and features that are impossible in the current CTB/ATB-scripts


The most basic change is that I'll invert the time/charge scale.


In current ATB's the player start at zero and can act when the meter has reached a predefined top. That creates a lot of limits and problems (like DoubleX wrote about freezing the scale at special skill mechanics etc).


Instead, the meter will count the delay and the battlers will be able to act when the meter reaches zero.


That will open the scale (not bound between zero and action like in regular ATBs) and remove all needs for freezing the delay counter.


Surprises, paralyse effects or special actions will simply add more to the (open-ended) delay and not require any special programming.


That form with the delay meter dropping is also needed for several tactical options, because the delay will not only be increased by the battler action and special effects, it will also be possible to delay an enemy action in various ways.


So the player will have to decide if he uses fast low damage skills that delay the enemy attack to give him more actions, or to use heavy damage skills that will delay the next actor action by several turns if the enemy survives.


It will also result in the first action selection being directly at the start of the battles (most probably the sequence will be sorted by small AGI-dependent random delays at start), giving the option to make the battles end faster than having to wait for the first action meter to fill in regular ATB's.

 

[deilin]

For the prebattle processing, you can do some of that with events in the troop on turn 0.


For one game I'm making, all encounters are enemy 1, "Enemy". it has 1 HP, 1 mp, no exp or loot or anything.


this gets the message "Enemy emerged," with no enemies seen on the screen.


I usually set up 3 enemy per troop. It then set's through a random series to decide is 1, 2, or all 3 will appear. If 1, 1 and 3 are killed off, and 2 transforms into an appropriate enemy. If 2, enemy 2 is killed off with 1 and 3 changing. during this time, you can decide of troop strength,transform the enemies and kill them off if weak, and get the loot drop, ir you can boost the enemy with states and heal them.


this still goes to battle screen, but, quickly can end a battle. You will neeed to add some wait commands because turn 0 is processed quickly and mainly used for "surprise" attacks.


In any case, I think there should never be free loot without a battle, even with a wimpy enemy. If they run, they should run and the player gets nothing. As annoying as a wimpy battle might be, they can nip at your HP and MP enough to use potions, cause statuse you have to cure, and, most of all, cost time, like it really would. It's almost as bad as when Lunar Legends came out and you had to decide if you wanted loot, or EXP, from battle.


At this point, you should do it map by map. If party strength is x, acticate a switch that checks for it before battle scene processessing, and ignore it if switch is activated.

 

[Andar]

No, turn 0 can't work for enemy changes in my case, because that only happens after battle processing has started - and I want the check for strength before battle reflect the resulting troop, not the placeholders.


As said I'll plan to use a regular troop event for all that, I just need it at an earlier time than turn 0.


As for loot or XP from lower enemies - that's why I consider handling that with a common event. I want to use this battlesystem for several different games, and with a CE I can make the balances without needing to rewrite the script.


The map-by-map idea won't work due to the way I plan to structure the area with non-linear access. Most of my games will have a large focus on exploration, and a map-based strength trigger would place limits on the design and mapping I don't want.

 

[DoubleX]

Given the answers so far, and due to some more research on my own, the system will be completely independent of the existing battlescripts.

This will also allow me to add some changes and features that are impossible in the current CTB/ATB-scripts

The most basic change is that I'll invert the time/charge scale.

In current ATB's the player start at zero and can act when the meter has reached a predefined top. That creates a lot of limits and problems (like DoubleX wrote about freezing the scale at special skill mechanics etc).

Instead, the meter will count the delay and the battlers will be able to act when the meter reaches zero.

That will open the scale (not bound between zero and action like in regular ATBs) and remove all needs for freezing the delay counter.

Surprises, paralyse effects or special actions will simply add more to the (open-ended) delay and not require any special programming.

That form with the delay meter dropping is also needed for several tactical options, because the delay will not only be increased by the battler action and special effects, it will also be possible to delay an enemy action in various ways.

So the player will have to decide if he uses fast low damage skills that delay the enemy attack to give him more actions, or to use heavy damage skills that will delay the next actor action by several turns if the enemy survives.

It will also result in the first action selection being directly at the start of the battles (most probably the sequence will be sorted by small AGI-dependent random delays at start), giving the option to make the battles end faster than having to wait for the first action meter to fill in regular ATB's.

I don't think I figured out any nontrivial difference between starting from zero to full and dropping from full to zero. To me, adding/reducing the atb fill percentage is the same as reducing/adding the delays, and the atb fill rate is the same as the delay drop rate. Maybe it's because I just don't get it yet though

 

[Andar]

I don't think I figured out any nontrivial difference between starting from zero to full and dropping from full to zero.

The difference is that there is no "full", no top limit.


Let's say the usual "turn" has 100 ATB-Points. So if a battler is hit by a 3-turn-paralysis preventing actions, that is done by simply adding 300 ATB-Points.


So the battler simply needs a lot longer until the next action at zero.


If the action goes from zero to 100 for action and you want to paralyse the battler, you would have to "freeze" the ATB-Fill and take a different count until that freeze vanishes.

 

[DoubleX]

The difference is that there is no "full", no top limit.

Let's say the usual "turn" has 100 ATB-Points. So if a battler is hit by a 3-turn-paralysis preventing actions, that is done by simply adding 300 ATB-Points.

So the battler simply needs a lot longer until the next action at zero.

If the action goes from zero to 100 for action and you want to paralyse the battler, you would have to "freeze" the ATB-Fill and take a different count until that freeze vanishes.

Going from 0 to 100% can also do what you want, just with quite some tweaks:

1. Right after a battler executed an action, the battler atb clock doesn't always have to be reset to 0 - it's just the closest replication of the default RMVXA battle behavior, but not the only option. You can set some battlers and/or skills to have the atb reset percentage as, say, 50%.

2. When a movement restriction state's added to a battler, the battler atb clock doesn't always have to be reset to 0 - it's just the closest replication of the default RMVXA battle behavior, but not the only option. The battler atb clock can be reduced instead, and some battlers and/or states to have such reduction as, say, 50%.

It's no nontrivial difference from using yours, as yours' atb points can't be infinite, meaning that It's to be capped somewhere. Let's say the cap is 300,000(insanely large). If the atb point reset right after executing an action is at most 150,000 atb points, and the battler gets hit by movement restriction states, there are at most 150,000 atb points to be added. It's the same as setting the atb reset percentage right after executing an action as always at least 50%, leaving at least another 50% room for movement restriction states to be removed.

 

[Andar]

meaning that It's to be capped somewhere.

No, that's exactly the point. Only if I use percentages it needs to be capped - but I will use a different form of mathematics that cannot work with percentages.

Let's start with an example that can be handled by both a fixed scale (percentages) and an open scale, and then go to the differences between them.

Assuming I want a design where the special action requires four times the numbers of a simple action.

In an open delay-based system that would result in skills getting assigned delay=100, delay=200, delay=300 or delay=400 as base values. No problem so far.

In a fixed percentage-based scale, that would mean the simple action gets 25% and the skills would be assigned 25%, 50%, 75% or 100% as base values. Again no problem so far.

Now assume that the game gets developed and into balancing, and I find out that for one enemy attack to work as intended, the player would need to be able to use five simple actions to keep everything balanced.

How to deal with that change?

In the open delay-based system I simply write delay=500 for that specific enemy skill - finished.

But what to do in the percentage based system? There are several options, but all with heavy disadvantages:

Redefining Maxaction 100% as five times simple action results in simple action being 20% - and I would have to edit six dozen skills and a hundred items who had their numbers based on simple action =25%.

Setting Maxaction as 125% will result in that enemy suddenly having -25% ATB if that action is used - and as you said yourself, calculating with numbers above 100% or below 0% gets a lot more complicated in an ATB.

Starting with a ridiculous reserve (like setting simple action =10% if you don't know if you ever need 100%) produces other problems (including the player wondering why the ATB-meter never drops below 70%).

--------------------------

If you define two points on a line (zero = 0%, action =100%), then you get a fixed scale. A fixed scale is an absolute requirement for the use of percentages - that is its advantage but also its disadvantage.

If you define only one point on a line (zero=action identical), then you get an open scale. It is absolutely impossible to use percentages on that scale, because there is no definition of any point as 100% - no cap, nothing.

That requires a completely different mathematic to handle it, and I admit that some people can handle percentages better than they could handle number relations (which are needed here). But as the advantage of not having a fixed scale, you can easily rescale and have a few more advantages during game development.

You said for yourself that it needs advanced handling if someone wants to use numbers above 100% - that is not needed when there is no artificial fixpoint for 100%.

Additionally I've a few battle mechanics not yet described here that are easy to implement in an open scale, but very problematical in a fixed scale with a 100%-cappoint.

So why should I implement percentage mathematics if I can handle the same with relative numbers and when the introduction of percentages only requires me to use complex programming that is optimized for options I do not need, when I can handle the numbers in a different way without percentages and get most of the options I want without additional programming?

 

[DoubleX]

No, that's exactly the point. Only if I use percentages it needs to be capped - but I will use a different form of mathematics that cannot work with percentages.

Let's start with an example that can be handled by both a fixed scale (percentages) and an open scale, and then go to the differences between them.

Assuming I want a design where the special action requires four times the numbers of a simple action.

In an open delay-based system that would result in skills getting assigned delay=100, delay=200, delay=300 or delay=400 as base values. No problem so far.

In a fixed percentage-based scale, that would mean the simple action gets 25% and the skills would be assigned 25%, 50%, 75% or 100% as base values. Again no problem so far.

Now assume that the game gets developed and into balancing, and I find out that for one enemy attack to work as intended, the player would need to be able to use five simple actions to keep everything balanced.

How to deal with that change?

In the open delay-based system I simply write delay=500 for that specific enemy skill - finished.

But what to do in the percentage based system? There are several options, but all with heavy disadvantages:

Redefining Maxaction 100% as five times simple action results in simple action being 20% - and I would have to edit six dozen skills and a hundred items who had their numbers based on simple action =25%.

Setting Maxaction as 125% will result in that enemy suddenly having -25% ATB if that action is used - and as you said yourself, calculating with numbers above 100% or below 0% gets a lot more complicated in an ATB.

Starting with a ridiculous reserve (like setting simple action =10% if you don't know if you ever need 100%) produces other problems (including the player wondering why the ATB-meter never drops below 70%).

--------------------------

If you define two points on a line (zero = 0%, action =100%), then you get a fixed scale. A fixed scale is an absolute requirement for the use of percentages - that is its advantage but also its disadvantage.

If you define only one point on a line (zero=action identical), then you get an open scale. It is absolutely impossible to use percentages on that scale, because there is no definition of any point as 100% - no cap, nothing.

That requires a completely different mathematic to handle it, and I admit that some people can handle percentages better than they could handle number relations (which are needed here). But as the advantage of not having a fixed scale, you can easily rescale and have a few more advantages during game development.

You said for yourself that it needs advanced handling if someone wants to use numbers above 100% - that is not needed when there is no artificial fixpoint for 100%.

Additionally I've a few battle mechanics not yet described here that are easy to implement in an open scale, but very problematical in a fixed scale with a 100%-cappoint.

So why should I implement percentage mathematics if I can handle the same with relative numbers and when the introduction of percentages only requires me to use complex programming that is optimized for options I do not need, when I can handle the numbers in a different way without percentages and get most of the options I want without additional programming?

Then you'll have to use a very different way to display your delays. Using atb bars(or circles, pies or whatever) always means fixed cap on both ends, as it needs a starting point and an ending point, and it can't have infinite length.

Perhaps you can display the delay points directly instead. In this case, displaying integers will be better(but the delay points themselves can still be floats). But then you still need to cap the maximum possible delay points, as the display area is always limited, and the more digits the delay points are, the more space they're needed for displaying(the digit size can't be too small either). While the maximum possible cap can be so high that it's practically almost impossible to reach, that cap still has to be there.

Of course, if you decide not to display the delay points at all, you can forget what I've been saying. But seriously, your open scale is only feasible when the numbers are not displayed at all

P.S.: When thinking of a feature, you need to think about it as a whole, and how it'll become a part of the greater whole, by thinking about how it'll interact with which other parts. I don't want to sound rude, but it seems to me that you haven't even think about how the delay points will be displayed at all

P.P.S.: Even if the internal uses the percentage system, the display can still seem to look like it's not. It can be displayed as if it's using your delay point system instead. Of course such cheating needs additional codes though lol

 

[Andar]

Oh, I've thought about the display - or rather I didn't even need to think about it because such displays existed years ago and it was always clear how it would be displayed to me.


The display method is one that has been used often for similiar things (basically a logarithmic instead of a linear scale):


Let's say you have 100 pixels for the bar. You display the bottom 50 pixel in green color with a scale of 1 pixel = 1 delay-unit (or whatever scale choosen)


Then you display the next 35 pixels in yellow color with a scale of 1 pixel = 10 delay-units


On top there will be 15 pixels in red color with a scale of 1 pixel = 100 delay-units.


That way you can directly display up to 1900 delay units in 100 pixel, and if the actor has more delay then there will be simply an overlay-symbol + or infinity to display that the scale is not sufficient. Due to the color coding, such a scale is quickly understandable by any user and they'll know that the display drops slower when the higher colors are reached.

P.P.S.: Even if the internal uses the percentage system, the display can still seem to look like it's not. I Of course such cheating needs additional codes though lol

That sentence basically summons up the problems I have with the idea of using percentages.
You say yourself: I need additional code to force percentages on the principle and make them work.


Why should I do all that additional coding work if I can make a system without that work? Where are the additional advantages of percentages that would convince me to make that additional coding?


OK, I understand that you're one of the people who can easily calculate with percentages and probably have problems with number relations, but I can use both equally.


And so far I don't see any advantage to be gained from using percentages. Yes, you need to think differently when using an open scale - like you need to handle the display differently as described above.


But those different methods do exist, so why not use them if they provide advantages above percentage calculations?

 

[DoubleX]

Oh, I've thought about the display - or rather I didn't even need to think about it because such displays existed years ago and it was always clear how it would be displayed to me.

The display method is one that has been used often for similiar things (basically a logarithmic instead of a linear scale):

Let's say you have 100 pixels for the bar. You display the bottom 50 pixel in green color with a scale of 1 pixel = 1 delay-unit (or whatever scale choosen)

Then you display the next 35 pixels in yellow color with a scale of 1 pixel = 10 delay-units

On top there will be 15 pixels in red color with a scale of 1 pixel = 100 delay-units.

That way you can directly display up to 1900 delay units in 100 pixel, and if the actor has more delay then there will be simply an overlay-symbol + or infinity to display that the scale is not sufficient. Due to the color coding, such a scale is quickly understandable by any user and they'll know that the display drops slower when the higher colors are reached.

That sentence basically summons up the problems I have with the idea of using percentages.

You say yourself: I need additional code to force percentages on the principle and make them work.

Why should I do all that additional coding work if I can make a system without that work? Where are the additional advantages of percentages that would convince me to make that additional coding?

OK, I understand that you're one of the people who can easily calculate with percentages and probably have problems with number relations, but I can use both equally.

And so far I don't see any advantage to be gained from using percentages. Yes, you need to think differently when using an open scale - like you need to handle the display differently as described above.

But those different methods do exist, so why not use them if they provide advantages above percentage calculations?

If you don't mind using overlay symbols + or infinity or something like those, and you think they'll work on your players(I can't and won't give any comment about this as you should know your targeting audiences well before making this decision), then yes, yours will work, and is likely better than the percentage scale.

Now let's drag back the focus of the discussions(it's me who drag the discussions out of their original focus lol) - from why and/or what to how(as I think doing so will be much, much more beneficial to this topic ). So you've decided to use the open scale delay point, you know what you're doing and you know it'll work on your players, let's discuss how it can be done now.

If I get your setup right:

1. At the start of a battle, the delay point of all battlers are all 0, unless some movement restriction states are already applied to some battlers at that moment.

2. When the delay point reaches 0, the battler has no movement restrictions, and the battler has inputted an action, that action will be executed.

3. When the delay point reaches 0, the battler has no input(like autobattle and/or confusion) and/or movement restrictions, and the battler hasn't inputted an action, that battler will be able to input actions.

4. When the delay point reaches 0, the battler has input(like autobattle and/or confusion) but not movement restrictions, and the battler hasn't inputted an action, that battler will automatically input actions.

5. When the delay point is above 0, the battler won't be able to input actions.

6. The delay point can be increased by finishing inputting actions, getting hit by movement restriction states, or something else.

Then the below components are what I think will be needed:

1. States/Skills/Items(and/or even actors, classes, weapons, armors, enemies) notetags specifying the amount of delay point added

2. Actors/Classes/Weapons/Armors/Enemies/States notetags specifying the rate of delay point decrement

3. Action input check - If the delay point reaches 0, if the battler's no actions nor which has no input confirm flag raised(player input if no input restirctions like autobattle and/or confusion; auto input otherwise)

4. Action input confirm flag(raised right after finishing inputting actions) used to check if the action input has been finished and the delay addition(and then decrement) should be proceeded

5. Dealy point decrement per frame with the rate based on the base speed(global battle speed) and the battler's speed stat(agi or whatever you/your players want)

6. Action execution check - If the delay point reaches 0 and if the battler's action has the input confirm flag raised

Before actually coding stuffs, however, I think you'll want to decide the degree of control and freedom you'll have when you use the script first.

On 1 extreme, configuration values are hardcoded whenever possible; On the other extreme, configuration values are RGSS3 codes that can be edited on the fly.

If you decide to make the script public, you'll have to think of other potential script user's demands of control and freedom, and their scripting proficiency. In general(with some exceptions), the higher the control and freedom, the more the scripting proficiency demand will be.

This decision will likely drastically affect the actual script implementations, and changing that decision after the script's implemented and be rather painful.

 

[Andar]

If I get your setup right:

Yes, that's basically correct

Then the below components are what I think will be needed:

1&2: agreed - but I would rather use datafields that are no longer needed than use notetags.

For example, the speed field of items and skills is no longer needed for turn sequence calculation, so it can now be used to store the delay points.

3-6: also basically agreed - but since I'm more interested in the tactical aspects of ATB's (different points for different actions) than the real-time aspects, there is a good chance that this might get simplified during coding.

For example I see no problem with pausing the entire sequence while an action is selected and executed, but I'll have to check that when I design the flowcharts for the system.

Before actually coding stuffs, however, I think you'll want to decide the degree of control and freedom you'll have when you use the script first.

Basically I prefer dynamic coding to hard coding. Even if I never publish the code, it will help me to reuse the code in different projects.

-----------------------------------

And now to a completely different aspect/idea that I had just last hour.

So far, we have always talked about a system where the action time is a fixed, skill-based number and the time rate variable and actor-based.

Example: Base Attack has a delay of 100, one actor might have a speed of 20/second and another actor with a 20% higher speed would have 25/second.

That would result in actor 1 being able to act again after five seconds, while actor 2 would have the next action after four seconds.

Now what if we turn that around and calculate the actor-based speed advantage into the delay numbers?

In that case, actor one would have the base delay of 100 and the actor two with the 20% speed advantage would execute the same skill with a delay of 80 - and both would keep the base fill rate of 20/second.

The timed result would be the same - actor one acts after five seconds, actor two after four seconds.

But the other differences might improve everything:

From the coding side, calculating the actor's speed factor into the action's delay number would be no problem at all, but the ATB-loop would be simplified as all battlers keep the same fill rate now.

From the player's view, the speed differences of the actors would suddenly become directly visible (different jumps on the bar display) instead of indirectly (only the fill speed difference)

I think that is an advantage for actor differentiation, even if the player has to adapt to a slightly different engine display behaviour. But since I change that display behaviour anyway, that is no disadvantage

Since the calculations are done in the code, the developer would still have the simple numbers for skill delay and actor speed that he wants.

But the fixed fill rate would make the coding much more efficient without loosing any of the ATB-options, since the actor's speed effect will simply be calculated elsewhere.

Opinions?