State Elements...

[Roguedeus]

We have Element Damage... And UsableItem Effects, like add state, etc... But nothing combined.

What if, a stun wasn't just a stun, but an ICE stun? All rates are effected first by element resistance, and then by effect resistance. Thus a target 50% resistance to ICE, and 50% Resistance to Stun, has a 25% total resistance against ICE Stun.

This is just a simple example. But it would make certain effects able to be applied much more liberally, when something Immune to an element, is by extension also immune to all that elements linked effects.

Meanwhile, an EARTH Stun, will work fine... etc.

Elements are purely cosmetic. It would be linked to element ID's and thus can be easily extended.

Now... How would the easiest way to implement it be?

If the effect is a state, the note tag could be on that state... But then, it would require every state of every element to be individually defined. What if the link were made on the UsableItem?

Thus, only one state is needed, and can be applied under different circumstances. Kind of like conditional effects.

This would mean that each blind effect could be assigned a different element ID dependency. Or the same dependency, under different conditions... etc...

[Roguedeus]

It appears that my Battle Tactics script is turning into a Advanced State Effects script...

Essentially it may seem redundant, but it will allow you to stipulate how much of dealt damage is converted to a state effect.

If you can't damage the target, there is no effect.

I am thinking I may eventually re-write it as a plugin for the State Mechanic.

On another front, my Advanced Parameters script is allowing for some truly dynamic parameters. I've done what I can think of to the reduce overhead of calling a lambda evaluation every time a parameter method is called... Also added a Parameter Lock so that a battler can have a dynamic param locked (until unlocked, and re-locked) in order to further reduce overhead.

[Roguedeus]

Well... That was harder than I expected.

Getting my custom Counter Attack to play well with Theo's SBS was frustrating. But I finely managed it. Its a little convoluted, and I may end up yanking it all together, but it was a learning experience none the less.

Essentially Counter Attack is no longer a defense. It still only triggers on a successful CNT check but does not skip being hit by the target. (No preemption) I am adding what I am calling REPOST which will trigger instead of counter attack, but only if you've evaded the attack.

• Counter = Possible free attack, when you do not evade.
• Repost = Possible free attack, when you do evade. (Presumably the attack is a different one)

The idea is that its easier to counter, when you leave yourself in the line of attack. Keep in mind that my Battle_v3 mechanic changes the way they HIT and EVA interact to where all attacks hit unless evaded. (No evade = always hit) Having no defense makes you a sitting duck.

Combine those with:

• Distraction = Reduce the targets EVA chance (that turn) based on the percentage of damage converted.
• Parry = Reduce the targets HIT chance (that turn) based on the percentage of damage converted. (This was originally supposed to boost your own EVA, but that was stupidly OP broken)

And I am thinking that there might be enough depth to the melee mechanic to spread over a large game.

[Roguedeus]

I wish there was a convenient way to prevent popup piles when the subject and user are in the same general space... But since popups are generated on current position, rather than original position, I am stuck with it for now... It may be something I get to eventually.

This is about as cluttered as popups get really. And its not so bad.

https://www.youtube.com/watch?v=qfvRCRF0w-o

[Roguedeus]

LOL... The counter attack mechanic causes fatigue to spike hard core.

In one action the target is either evading, hitting, and countering or reposting... That is a base of 3 maneuvers in a single action that can multiply by the number of targets that trigger it. Not including the misc adjustments to fatigue generation for each maneuver.

If you have a counter attack build, you need some serious fatigue removal.

[Roguedeus]

Maybe I can allow for a state flag that would disable counter and repost while active. The player would use it as a 'stance' so they can avoid the fatigue hit it comes with, strategically.

[HimeWorks]

Sounds like a complex battle system.

[Roguedeus]

Its individual systems all interacting with each other more than a single monolithic construct.

The complexity is in trying to make sure that my inexperienced code doesn't cause it to break down.

Stances are part of the system already, as a replacement for front row, back row, positioning. I call them aggressive and defensive stances. I am thinking I'll create alternate stances that will function like a low fatigue stance, and a high fatigue stance. low fatigue meaning fewer of the auto use functions of things like counter attack occur.

edit: High fatigue stances would be like hitting nitro boost on your car engine. Not something you want to do for any length of time, but sometimes very necessary.

[Roguedeus]

I will trickle the complexity out to the player over time. Many players won't even notice the fine details. They may just choose to play with an Ardent in their party because they like tankish warriors with big shields, or the Cut-purse because they want to pick pocket enemies and pick locked chests... Etc...

Meanwhile others will choose the Ardent because they can wield large shields and strategically intercept damage for team mates like the Cut-purse that is only in an aggressive stance so that they can pick pockets more effectively, but at an unreasonable risk without an Ardent next door.

Etc...

:)

[Roguedeus]

Last week I put in ~51 hours of straight coding... Every minute of it time lapse recorded. (That is 100% productive time... I don't record most of my notes or research)

It doesn't seem like much in simple numbers but I am beginning to feel the burn out. Especially since my passion is design and content, NOT CODE... I've been going like this for the last three weeks. Slightly less productive for about three weeks before that.

Essentially, I have been burning the candle at both ends for nearly two months now, and I have gotten a TON of coding done.

I can see the end of the tunnel.

Pretty soon, the only coding I'll need to do for a while will be incidental or bug fixing. I will do my best to refuse to write entirely new systems until the combat mechanics are ironed out and I release my battle demo for feedback... Then move into mapping and environment (Which will be MUCH easier for me).

[Roguedeus]

Ok... A trait is a special state that is pretty much permanent. Some traits are always ON and some can be toggled ON or OFF.

Some traits can require consumption of charges to bestow their effects. (To see them as active states) while others are always effective. Of the traits that consume charges, most can be toggled ON or OFF, but not all.

The primary risk of having a trait ON (besides running out of charges) is that a new state or trait can come along and interfere with it by resisting it. A resisted trait is NEGATED as long as the resisting state is active.

Only ON traits can be negated, and can not be turned OFF while being negated. They are effectively scrambled, or locked down, without effect. Draining away.

Should the resisting state be removed, the NEGATED trait is instantly UN-NEGATED and if it still has charges (if it consumes charges) then it is active and effective again. Otherwise, it will become disabled as if it had just run out of charges. It is essentially un-negated only to remain disabled until it has charges again, or is turned off.

Here is my dilemma.

A player might have more than a few traits that can be toggled on or off, and they may not always be aware of their current charges, especially if the trait is active outside of battle. Without constantly checking the menu status for state charges.

Do you think that a togglable state should automatically turn itself off if it runs out of charges? That way the player doesn't have to turn it off to prevent it from being negated. If so, the player will have to re-toggle it ON regularly.

Or should it simply become disabled, and then auto enabled when a charge is regained? This will reduce the players micro-management but make traits more vulnerable to being negated unless the player pays close attention to which traits remain ON.

Of course, then there is the issue of indicating to the player that a trait is ON but disabled. If a trait is disabled, then it has no active VISIBLE state. So how would they know its still ON? This has lead me to favor the Auto-Off when charges are empty (for togglable traits that require charges)

It seems complex when I try to explain it, but it is rather simple... Its just this ONE detail can have some pretty important impacts on trait utility and difficulty of use in later stage games where actors may have half a dozen or more togglable traits.

[Roguedeus]

An example of a trait with charges that is toggled might be an anti-magic field. The actor may be a race or creature that has a natural anti-magic barrier that must re-charge when turned off. While on, it uses charges, and has an anti-magic effect on the actor. However, it can be negated via a some state effect like 'sleep' or 'stun'... While negated it is still ON and consuming charges, its just not having any effect.

It may not be the best example, but its convenient.

[Roguedeus]

No opinion?

[HimeWorks]

It is hard to see how it will work out without some prototype On Oct 1, 2015 8:20 AM, "Roguedeus" notifications@github.com wrote:

No opinion?

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/285#issuecomment-144710753 .

[Roguedeus]

Fair enough... I think I will implement both options and test them both.

I am also noticing that one of my core design decisions in my state mechanic is a mistake. I hope it doesn't consume to much time changing. (Part of the move to more modular code)

[Roguedeus]

Have you ever noticed that you can flag a state as both restricted AND remove by restrict?

Which means that it will end up removing itself.

Not to mention any aberrant behavior that contradiction might cause in advanced battle systems. I am SOOOO lucky I noticed that because I was about to blow a lid tracking down an a battle hanging bug...

[Roguedeus]

On the flip side.

Silver lining is that contradiction actually showed me a RARE possible bug in my AP Battle System... Fixed. It was the only possible way that an enemy might call the next_command method without an action object. Causing it to freeze.

Because of the dynamic nature of action choices now, a confusion had to exist prior to the enemy acting, and then be removed prior to the enemy acting, to cause the nil action.

[HimeWorks]

I didn't notice the remove on restrict and restrict actions. But I'm sure someone would realize they are complete opposites of each other On Oct 1, 2015 16:43, "Roguedeus" notifications@github.com wrote:

On the flip side.

Silver lining is that contradiction actually showed me a RARE possible bug in my AP Battle System... Fixed. It was the only possible way that an enemy might call the next_command method without an action object. Causing it to freeze.

A confusion had to exist prior to the enemy acting, and then be removed prior to the enemy acting, to cause the nil action.

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/285#issuecomment-144842497 .

[Roguedeus]

I didn't think a states own flag would effect it. What if you wanted the state to break if the target was immobilized? You'll need to make ALL possible immobilizing states present and future, resist it.

[HimeWorks]

True. I would be curious how people are doing that.

[Roguedeus]

The video I just posted to my twitter got me reconsidering my simple Damage Delivery system and considering creating a 'Battler Size' plugin, supporting weapon type vs. target size comparisons.

[Roguedeus]

Non-special weapons should have a single delivery. Special weapons might have more than one. Uniquely special weapons might adapt to the target dynamically (like a hammer that grows to crazy size when fighting giants).

The idea is that small weapons, are good vs. small things and larger weapons are good vs. larger things. But in reverse, they are worse. Using a large weapon vs. a small target is relatively slow and inaccurate... etc...

It is an abstract that most games mechanics completely ignore. But why?

Besides the typical, RNG to balance everything doctrine, I am thinking its simply a matter of most people not considering it. It is rather difficult to imagine exactly how difficult it might be to fight an enemy the size of a house. So we just slap more health and defenses on it and that's that.

At most mechanics give such targets special resistances of some sort, like in Dungeons and Dragons some creatures require +3 or better weapons to even be hit by an attack, etc... It is presumed this means that the +3 makes the weapon 'able' to slay a dragon the size of a building.

Now I just need to bend the process into my existing Damage Delivery & Nature system so that it remains as intuitive and low maintenance as possible.

My first impulse is to simply create new weapon types with a prefix like Massive or something, and then put new tag checks for target size comparisons in the mobility checks vs. delivery.

[Roguedeus]

This new abstract can also encourage new state effects, such as an Enlarge state that temporarily gives a battler the massive tag or something... etc...

[Roguedeus]

OMG... I just about lost my marbles.

Spent 3 hours doing my best to understand a recursive method call only to throw my hands up and simply take the part causing the recursion out of the method and do it 'before' the call... And it works.

I could have saved myself 2+ hours of frustration.

It seems that despite my recent code progression, I am still woefully unable to wrap my head around recursion enough to do anything more than avoid it if at all possible.

[Roguedeus]

Oh fracking hell... New freeze battle bug discovered... FML... LOL

[HimeWorks]

Finding a bug is a good thing On Oct 3, 2015 19:07, "Roguedeus" notifications@github.com wrote:

Oh fracking hell... New freeze battle bug discovered... FML... LOL

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/285#issuecomment-145296558 .

[Roguedeus]

Today has been one error and bug after another. ;)

I suppose I shouldn't be surprised. I am refactoring code I wrote several months ago. Before several key practices 'clicked' for me...

[Roguedeus]

2/3rds of the core States Engine is complete.

Normal States function normally, with the exception that they can be Hardened so that other states can not Resist them unless they have been dispelled first. Hardened states become more difficult to remove once applied.

Essentially dispelling is a weakening condition that any state can be given, but it is only really necessary to use against normal states when they are hardened.

Feature based RESIST works normally. A state can only harden if successfully applied. Thus a ring of poison resist (feature RESIST: Poison) will completely prevent that state, even if it is normally hardened after applied. But if that ring was only (feature RATE: Resist 50%) and the poison managed to get applied, then it becomes hardened, and must be removed via (effect REMOVE STATE: Poison) or it must be dispelled first and then a resisting state applied.

This complexity is for a few reasons... First, almost ALL state removal will be feature RESIST based, so that an action must apply a removing state to the target in order to remove most states. This is because many targets can't have certain states applied to them, for one reason or another. (Such as an opposing ethos can't have a cure state on them from their opposing faith). Note tag controls will prevent actions from targeting them in the same manner. However, POTIONS and other items that are not necessarily origin related (straight alchemy) have effect removes. Which are always effective, even against hardened states.

[Roguedeus]

Permanent States are relatively independent on their current charges. They will remain on the target until they are dispelled (weakened) and then removed. Normal (effect REMOVE: State) and (feature RESIST: State) will remove a dispelled permanent state.

Unless that is, if that permanent state has been Hardened. ;)

A hardened permanent state, must first be drained of all its charges (manually, via remove charge actions) before it can be successfully dispelled. At which time it can be removed as noted above.

This complexity is born of a desire for there to be states that get worse, each time they are applied, requiring more and more effort to remove them. Thus a hardened PERMANENT state with 10 charges might take a single potion to remove, where as one with 30 charges might take 3 potions... etc...

Plugins will more dynamically manipulate the charges.

edit: Also, the general idea is that a dispel effect is rather rare and not something you will normally have access to outside of a city or base of operations. Thus, the focus for such states must be PREVENTION PREVENTION PREVENTION. Or it will be a pain to get rid of them. most especially because its easier and CHEAPER to prevent. (aka: Thinking ahead has its benefits)

[Roguedeus]

I will give each type of state its own boarder color, so people will know immediately which is a normal and which is a permanent state. (And which is a Trait State, once they are done) As a matter of fact, it would be awesome if there was a script that allowed for icon layers...

[Roguedeus]

Can you remind me how to easily prevent more than a single level of recursion?

[HimeWorks]

The trick I see people using is to set an instance variable

def recursive(num)
   return 0 if @checked
   @checked = true
   res = recursive(num + 1)
   @checked = false
   return res
end

So the first time you run it, @checked is false...so then you proceed with the recursive call. The second time you call it, it's true, so you just return some base case value.

Upon returning from the recursive call, you reset the checked flag, and return the results you want.

[Roguedeus]

What if I wanted to allow only a limited number of recursive layers? Like, two or three? Is there a similarly simple trick?

[HimeWorks]

Well, instead of using a boolean you can just use a number as a counter. Though ideally you would define your method with a local counter variable.

[Roguedeus]

But it would only ever preempt the actual recursion with a predetermined value a number of times? Rather than collapsing through to completion?

[Roguedeus]

Is this a reasonable solution?

@x = []
def recursive(num, check = 0)
  @x << num
  recursive(num + 1, check+=1) if check < 3
end
recursive(0)
puts(@x.to_s)
#[0, 1, 2, 3]

[Roguedeus]

Essentially I am toggling objects on and off based on the current collection of on and off objects. But when two or more objects ping pong each other on and off, it could result in an infinite loop.

While I am hoping that I can keep the toggle intersections controlled so that this wouldn't happen, the last thing I want is to introduce a stack overflow or freeze error into an advanced game that may cause progress loss.

I figure, after a number of ping pongs, all objects in question will simply turn themselves off and a small message will explain why. Kind of like plugging in something pops a circuit breaker (turning everything off) rather than fry the entire rooms electrical lines and possibly burn down the building. ;)

[Roguedeus]

Well... It seems that I was getting a little ahead of myself again. I still have things to add to normal and permanent states before I go engineering traits.

Primarily, conditional states.

I've made RPG::State objects references inside of State objects. The State is interacted with in very much the same way as the RPG::State object would be only now the State object can alter itself dynamically and carry a lot more data around. Such as who applied it to the battler its riding inside and how many charges each applier owns.

This way, multiple attackers can 'pile on' a state, each only able to apply a maximum number of charges based on their individual parameters. While also capping the total charges by a state maximum, that can be dictated by the targets parameters.

This will include faster or slower charge removal, as well as application resistance or weakness to charges. Think of an attacker applying 2 charges to a target with a +1 charge adjustment (weakness) to that state. It will result in 3 charges being applied, rather than just 2. The reverse is the case as well. So some targets will require that the application be greater than a number of charges in order to even effect it.

Of course, the state would still need to break through any existing default rates of application.

Constitution is also factored, where the target can shed more than 1 charge in a single turn. If the state has a duration of more than 1 turn per charge, then constitution simply speeds up that turn count by its value instead.

This way a more powerful caster of a spell will effectively apply more charges (or turns) of a state and a target might be effectively immune to the application of that state until its total applied charges (per use) is above a certain threshold. OR the attacker can reduce said targets soft resistance (in charges) to a low enough level that it can be effected...

I'll also note that most enemies will never have a feature resist against any state. Instead, they will have traits that grant them the feature resist. However, that trait will be able to be negated by the right counter-state, removing that resistance. Of course, the challenge then is to find a source of that counter-state... Etc...

In general, I am doing my best to develop a set of systems that are rarely if ever absolute. The solution to overcoming any obstacle is available with the right amount of planning and application. Even an impossible enemy can be rendered effectively impotent with the right application of countermeasures. That is, as long as you find and afford to use them!!

[Roguedeus]

I usually get so little done on pizza days... But sometimes I just want pizza. :)

[Roguedeus]

By the way. I forgot to thank you for the quick reply. I was a little preoccupied.

Thank you!

I have not gotten to where I can test my solution yet, so I may re-visit it in the near future.

[Roguedeus]

I tell myself that I really shouldn't allow life stress to interfere with my creative pursuits and to do so is a liability... Doesn't help much.

[HimeWorks]

If only there was a way to integrate creativity into daily lfie.

[Roguedeus]

I am giving myself the impression that I won't be getting much done this weekend.

[Roguedeus]

Some last minute respite... Not so terrible resolution in sight.

Potential of focus improving.

[Roguedeus]

last night, I think I had a slight epiphany regarding my class structure... How to weave in the Deistic order, and help maintain a workable variety without going to variety insane.

However, it will require me finishing up the States Engine and spending some time ironing out the Deistic Favor mechanic and Ethos Cogence which is sort of like a morality bar for individual actors.

When an actor (with an Ethos based Class) risks losing their Cogence with their Deistic Order (the powers that embody their Ethos) then they will leave the party. So if you want to keep your Ethos Class actors you can't do to many things that run contrary to their Ethos.

The opposite is that actions that strengthen the actors Cogence will have beneficial effects, like more powerful abilities. Cogence is a percentage based measure. An Ethos Class must have 100% Cogence to call on their most powerful Deistic Invocations.

Imagine Cogence is the quality of the link between a worshiper and their God.

Non-Lore Mechanic: Essentially this mechanic will make having party members of widely divergent Ethos almost impossible to maintain for any length of time. One or more actors will leave the party in protest, or not join at all.

In D&D and other P&P RPG's this is known as Alignment. A Paladin is not allowed to adventure with people known to be evil. Etc...

[HimeWorks]

Alignment seems like something that you would be spending most of your time eventing.

[Roguedeus]

A agree. It is one of those things that I have really tried to refine my ideas to include without requiring to many 'exceptions' to accommodate.

One of the things that occurred to me is that many people making open(ish) worlds do so including a morality bar. So if you do to many evil things, then good people and good quests become your enemy (or simply removed from access).

They also tend to include a faction system where doing quests or whatever for one faction, gains you benefits with it, while causing trouble with other factions.

While planning my plot arch and history its dawned on me that I can simply move those two things from a purely abstract form, into a very specific one. Factions become Deistic Orders, and Morality Bars become Ethos Cogence.

Etc... I am hoping that when it comes time to eventing these things, that I can do my best to reduce the tedium through script calls. Though it will require a small bit of heavy handedness with things like Shrines and Temples.

Entering a dungeon with a shrine to a specific Deistic Order, will play into your parties current Deistic Favor with that Order... A negative favor will automatically cause bad things (like higher level encounters, etc...), while a positive favor will allow you to invoke the Deities favor to change the dungeon in some measurable way. (such as reducing the level range of encounters, the lethality of traps, or removing permanent states from party members... etc...)

You can prevent this interaction through destroying the shrine somehow, but that will have its own set of pretty serious consequences...

[Roguedeus]

Yanfly's base scripting for MV looks awesome.

Is he paid by Degica?

[HimeWorks]

I have no idea lol. On Oct 11, 2015 20:11, "Roguedeus" notifications@github.com wrote:

Yanfly's base scripting for MV looks awesome.

Is he paid by Degica?

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/285#issuecomment-147259056 .

[Roguedeus]

I would hope he is... I think he single-handedly doubled the adoption rate of VXAce and looks to be the default script batch for MV.

edit: I also wonder if Theo worked with him on the battle mechanic. So much of the action sequence stuff is almost identical to Theo's SBS.

[Roguedeus]

Its gotten where I need to keep a glossary now in order not to re-use the same terms for different events, effects, and plot devices. ;)