devolution

Author Topic: BE logic  (Read 31382 times)

0 Members and 3 Guests are viewing this topic.

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: BE logic
« Reply #15 on: November 14, 2015, 02:23:25 PM »
core.rpy
Quote
        def get_defense(self, target):
            """
            A method to get defence value vs current attack.
            """
            if any(list(i for i in ["melee", "ranged"] if i in self.attributes)):
                defense = round(target.defence + target.constitution*0.2)
            elif "magic" in self.attributes:
                defense = round(target.magic*0.4 + target.defence*0.4 + target.constitution*0.2 + target.intelligence*0.2)
            else:
                defense = target.defence
            return defense
content-classes.rpy
Quote
    class PoisonEvent(BE_Event):
        def __init__(self, target, source, effect):
            self.target = target
            self.source = source
            if target.constitution <= 0:
                self.counter = source.intelligence+2
            else:
                self.counter = round(source.intelligence/target.constitution)+2 # We remove the event if counter reaches 0.
            self.effect = effect / 1000.0
            self.attributes = ['status', 'poison']
Assuming that you pulled.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: BE logic
« Reply #16 on: November 14, 2015, 02:59:18 PM »
Should be fixed.
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: BE logic
« Reply #17 on: November 15, 2015, 07:53:20 AM »
Such a lazy workaround I could implemented by myself  :D
It still will force us to add more additional checks in BE with every division.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: BE logic
« Reply #18 on: November 15, 2015, 12:41:24 PM »
What do you propose? I've already said that defense stat should be able to be 0. That method looked like something that you wanted to use to calc defense in the BE, where else are you planning to calc it?
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: BE logic
« Reply #19 on: November 15, 2015, 01:06:02 PM »
I want to add effects to every spell. The chance to resist effects will be calculated in a similar matter. Also evasion. Also who knows what.
I figured if you don't like tons of unnecessarily elif forks, you won't like tons of unnecessarily "if a <= 0: a = 1" checks too, and normalization that does not allow stats to be less than 1 (except luck) will do the trick. Oh well, not my problem then if you will want to get rid of <=0 checks one day  ::)
« Last Edit: November 15, 2015, 01:08:30 PM by DarkTl »

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: BE logic
« Reply #20 on: November 15, 2015, 01:18:48 PM »
Well... I can tweak the Stats class to prevent a number of stats from ever returning 0. This just seems weird to me, I don't think that we've ever had one ZeroDevision error in three years or so and now we all of a sudden are going to have to deal with them in multiple places at once?

If you really anticipate a a lot of checks, I'll take a look at your code, there must be workarounds to prevent that. We now have mins/maxes/stats/lvl_max/different stat ranges/modification checks and etc. Adding yet another check to the system feels off, at least to me :(

Like I've said, I'll do it of there is no simple solution that will suit your code, it'll be simpler than dozens of checks all over the place. I just need to see at least a couple of these checks and why/where are they required.
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: BE logic
« Reply #21 on: November 16, 2015, 02:38:34 AM »
I don't think we ever worked with division when using mobs, and chars have normalization, so even if there is a chance for them to have 0 stat, it's pretty low as far as I can tell.
You actually had an old workaround for defence in BE already, probably because even chars used to have defence less than 1 before the normalization. So your recent fix was an overkill. That's why we never had issues with BE.

I encountered it two days ago after I added a formula for the number of turns for poison and tried it on mob. It's int/const. I realize that this is because mobs don't have constitution yet (I'll fix it asap), but the chance of CTD will remain.

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: BE logic
« Reply #22 on: November 18, 2015, 09:55:45 AM »
Content-classes.rpy
Quote
def show_gfx(self, target):
            # Simple effects for the sword attack:
            char = self.source
           
            battle.move(char, battle.get_cp(char, xo=50), 0.5)
           
            gfxtag = "attack"
            bbtag = "battle_bouce"
            self.effects_resolver([target]) # This can also be moved elsewhere. This causes the actual damage.
            self.apply_effects([target]) # This can also be moved elsewhere. This causes the actual damage.
            s = "%s"%target.beeffects[0]
            if "critical_hit" in target.beeffects:
                s = "\n".join([s, "Critical hit!"])
            txt = Text(s, style="content_label", color=red, size=15)  # This I should (prolly) move to a separate class/function. For now it is here:
            if self.sfx:
                if isinstance(self.sfx, (list, tuple)):
                    sfx = choice(self.sfx)
                else:
                    sfx = self.sfx
                renpy.sound.play(sfx)
What's this? Don't we have all this stuff handled in different places already? Looks like an outdated code, we calculate damage and check for effects like crit hit in core.rpy.
« Last Edit: November 18, 2015, 09:59:22 AM by DarkTl »

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: BE logic
« Reply #23 on: November 18, 2015, 01:37:46 PM »
Content-classes.rpyWhat's this?

This is the method that is taking care of the graphics... incidentally, it is also actually calling the method that calculates the damage and the method that applies the effects.

As I've previously said, BE has never been reviewed, I've coded the entire 1500 lines of code in two or three days of time without giving it much of a thought so whatever proved to be most convenient at that instant, was good enough.

Quote
# This can also be moved elsewhere. This causes the actual damage

It is not reasonable for a method that handles the graphics to call methods that are 5 times more advanced and handle hoards of complex and important thing, it was plainly the most convenient path at the time.

===
Plainly put:

Don't we have all this stuff handled in different places already?

We do, but just in the code. The code is executed where the methods are called, just because it was convenient, I called the calculation methods inside of the method that took care of graphics (and some sound effects). This will prolly be revised and it doesn't effect the code inside of the methods themselves (as in it would not matter if we write the action method to handle everything separately with one by one logical calls).
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: BE logic
« Reply #24 on: November 18, 2015, 01:57:40 PM »
I see. I was confused by "Simple effects for the sword attack:" comment, since we obviously have more attacks than just sword.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: BE logic
« Reply #25 on: November 18, 2015, 05:04:32 PM »
It's also poor comments since that class handles all the none magical attacks (not just the sword one)... I want to fix both the comment and the order of execution, it made little sense to have the graphical method calling the calculation methods in the first place. There was obviously the reason for that, but that reason was plainly a linear order of execution of events. Sim'Py, modern Ren'Py Multi-threading and my better understanding of UDD's all nullify "linear" progression.

Fixing that should be very easy one way of another, simplest two ways are:

1) Sim'Py:

Pros:
- Pure Python code and execution
- Easy to manage
- Full (110%) control of anything, no matter how complex

Cons:
- Impossible to save during an execution of battle scenario, game will plainly crash. That will never be fixed, no matter what the hell we do... We can save just before or upon completion of a battle.

2) Multi-Threading:

Pros:
- Full compatibility with Ren'Py saving mechanism.

Cons:
- Less control, upon finishing of the new thread, Ren'Py interaction will be restarted. Since Multi-Threading in the engine is a new thing (very recent thing) all together, I cannot say if this can be overcome or not because I have not seen the code that executes a new thread (yet).

3) UDD:


A possible but a very bad option... I do understand that it is a possible workaround but it is a bad one...
Like what we're doing?

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: BE logic
« Reply #26 on: November 18, 2015, 05:09:44 PM »
Oh, and the plainest solution is a loop that can request pause like in Jakes BE, that however does not solve multiple commands at the same time in a meaningful way like Sim'Py/Multi-threading do (both solve it utterly and completely)...
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: BE logic
« Reply #27 on: November 20, 2015, 08:41:23 AM »
In my opinion, saving inside of BE is the worst form of save scamming.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: BE logic
« Reply #28 on: April 25, 2016, 03:28:38 AM »
Quote
    Melee fighters are lacking BE skills compared to mages, even though we have plenty of animations for them. I imagine they should support critical hits and calculate damage based on attack and defense like normal attacks, and use vitality and sometimes health to be activated.
    Really, we cannot make a release when all non-mage fighters have just one basic skill.

Concept Proposal: Add "AP" that will exist just in BE. We will calc it based on constitution, agility, level and traits or vitality as you suggested.

- Normal attack will always be free.
- Other attacks cost these points. We'll add skills to mages that can restore those points for warriors. Maybe mages who do not have combat basetraits should always get 0 of those AP or be maxed out at 1...

Quote
    Since we have different weapons, these skills should be tied to base attack types. Like, some ranged skill could require BowAttack or ThrowAttack available to be used.

Maybe... that would have to be a new mechanic (yet another new mechanic on top of everything else...). I think those new skills should be bound to weapons... or we can come up with yet another complex system and bind them to classes/weapons combos :D

In any case, we need to think this through properly to try and come up with something that will stick.

Also an option to add stuff like double attack/triple attack, with simple animations...

Quote
    We have base attack type in characters jsons that should be used if they are unarmed. Equipping a weapon though should add a basic skill provided by that weapon (like swordattack for a sword) to attacks list, meaning we should carefully handle cases when a character already has swordattack, just like with traits.

Stuff like this usually falls into place as I code the system, but I'll try to keep it in mind (it may work like that already, I don't remember offhand but I'll check it tonight).

Quote
    Support for absolute values for cost of spells and battle skills, like 50% of max mp, would help to balance powerful high level skills without making them impossibly demanding. This should work in addition to normal cost, to prevent low level mages from using it. Like, cost = 100 abs_cost=50 mean it costs 50% of mp, and these 50% should be at least 100.

I don't like this one :( I'd rather put time constraints on super advanced spells (like you need a week of cooldown time after using it). But it's yet another mech...



Don't get me wrong, it's not like I am complaining :) We need interesting mechanics like these! That player could feel, work with, try to calculate and that do not require hours of micro but I do not want to do anything to specific without a good deal of discussion anymore because that costs insane amount of coding time, we've been burned by stuff like this too often.
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: BE logic
« Reply #29 on: April 25, 2016, 03:51:40 AM »
Concept Proposal: Add "AP" that will exist just in BE. We will calc it based on constitution, agility, level and traits or vitality as you suggested.

- Normal attack will always be free.
- Other attacks cost these points. We'll add skills to mages that can restore those points for warriors. Maybe mages who do not have combat basetraits should always get 0 of those AP or be maxed out at 1...
Well, I'd like to have health based skills in the future anyway to have "all or nothing" skills that take a lot of health but also are very strong. "Night [char.name]", if you know what I mean  :)
But yeah, battle APs are a decent way too.


Maybe... that would have to be a new mechanic (yet another new mechanic on top of everything else...). I think those new skills should be bound to weapons... or we can come up with yet another complex system and bind them to classes/weapons combos
You see, some animations are clearly intended to be used with a very specific weapon. Like some energy axe slashing hither and thither, there is no way we can use it with a club or something. And the best way to find out what kind of weapon we use is to look at the base skill it has, so axes always will have AxeAttack.

I'd rather put time constraints on super advanced spells (like you need a week of cooldown time after using it).
Yeah, it will work too. Either once per N days, or once per battle.