Pink Petal Games

PyTFall => PyTFall: Game design => Topic started by: DarkTl on November 11, 2015, 05:16:21 AM

Title: BE logic
Post by: DarkTl on November 11, 2015, 05:16:21 AM
Alright, at the moment it works like:
1) min damage is 0.
For weapons attack power is
attack = (a.attack + self.effect) * self.multiplier
Though weapons don't have anything like that. Should I add effect and multiplier fields to jsons?

For magic it's attack = (a.magic + self.effect) * self.multiplier. Now I see why spells are so OP, I'll change spells stats  :)
However, we use pure normal defense against magic based attacks. I want to change the formula, making it based on defense, magic and intelligence.

2) Damage from weapons is based on the difference between attack and defense:
Quote
         if (t.defence < 1):
                defence = 2 - t.defence
                damage = attack * defence
This is a weird code. Not sure why you cannot just
Quote
if (t.defence < 1):
    damage = attack * 2
Unless you expect negative defence, which probably should not even exist.

And for normal defense damage = (attack/t.defence) + 0.5.

Then we take a random number between 0.8 and 1.2, as rand, and
damage = int(float(damage) * multiplier * 10 * rand)

It works surprisingly well. You will have 15 damage if attack=defense, and in order to have damage 200 attack should be 19 times more than defense, so you clearly don't have enough training in the case if that's the damage made by enemies.

3) Multiplier means critical hits and elemental affinities.

Critical hit:
Quote
                if dice(10):
                    if (a.luck >= t.luck and dice(max(50, a.luck*2))) or dice(50)
So thanks to that "or dice(50)" the chance always will be 5% at very least. With max luck it will be 10% at best. That makes negative luck not a major issue, and makes max luck not a very big advantage. I want to change a bit crit hit chance, especially add bonuses based on occupation (warriors in general, assassin especially). Meaning a new field for traits.

Critical hit makes multiplier from the damage formula 2.5, thus makes it 2.5 times more. I want to change the damage of crit hits based on weapon type. Daggers will have more crit damage, and so on. But don't know how. I don't think we can use char.eqslots["weapon"].type inside BE, since BE doesn't know about equipment screen.

For spells it simply adds or removes % of damage based on elemental traits.

4) Poison:
- (magic + intelligence) should be more than target's
- cannot be poisoned again if already poisoned. I don't like it, it should reset the amount of turns left for poison.
- base damage = t.get_max("health") * (self.effect/1000.0). Ie based on target's max health.
- then we have a weird line damage = max(randint(18, 22), int(damage) + randint(-4, 4)). So it can never be less than 18. That's pretty high for weak chars.
Also I don't see where you control the amount of turns which the poison will work.

5) Healing:
- base amount of healed points is (effect + (char.intelligence + char.magic) * 0.25)*multiplier
It's sufficient for now, since we don't have many healing spells. In the future though I want to limit the power of weak spells, making high level ones much more useful for high levels.
Title: Re: BE logic
Post by: Xela on November 11, 2015, 06:30:42 AM
Alright, at the moment it works like:
1) min damage is 0.
For weapons attack power is
attack = (a.attack + self.effect) * self.multiplier
Though weapons don't have anything like that. Should I add effect and multiplier fields to jsons?

For magic it's attack = (a.magic + self.effect) * self.multiplier. Now I see why spells are so OP, I'll change spells stats  :)
However, we use pure normal defense against magic based attacks. I want to change the formula, making it based on defense, magic and intelligence.

Do as you wish. You can add fields to JSONs if you like, I don't remember if I had any specific ideas for BE, I always wanted special attacks bound to some items and to extend capabilities of SimpleAttack class but I left that for later, you can do whatever you can right now.

2) Damage from weapons is based on the difference between attack and defense:This is a weird code. Not sure why you cannot justUnless you expect negative defence, which probably should not even exist.

And for normal defense damage = (attack/t.defence) + 0.5.

Then we take a random number between 0.8 and 1.2, as rand, and
damage = int(float(damage) * multiplier * 10 * rand)

It works surprisingly well. You will have 15 damage if attack=defense, and in order to have damage 200 attack should be 19 times more than defense, so you clearly don't have enough training in the case if that's the damage made by enemies.

We had negative defense due to traits messing up stats, it shouldn't happen anymore.

3) Multiplier means critical hits and elemental affinities.

Critical hit:So thanks to that "or dice(50)" the chance always will be 5% at very least. With max luck it will be 10% at best. That makes negative luck not a major issue, and makes max luck not a very big advantage. I want to change a bit crit hit chance, especially add bonuses based on occupation (warriors in general, assassin especially). Meaning a new field for traits.

Critical hit makes multiplier from the damage formula 2.5, thus makes it 2.5 times more. I want to change the damage of crit hits based on weapon type. Daggers will have more crit damage, and so on. But don't know how. I don't think we can use char.eqslots["weapon"].type inside BE, since BE doesn't know about equipment screen.

For spells it simply adds or removes % of damage based on elemental traits.

Ofcourse we can use slots directly inside of the BE, there is nothing to prevent that. They will be bound to the characters object we pass around in BE, usually something like attacker/target. Those are full chars, they are exactly the same in all places of game/code, only one instance of them exists with nay amount of references to it. I wanted to add extra CS bonuses based on some weapons but never got around to that.

4) Poison:
- (magic + intelligence) should be more than target's
- cannot be poisoned again if already poisoned. I don't like it, it should reset the amount of turns left for poison.
- base damage = t.get_max("health") * (self.effect/1000.0). Ie based on target's max health.
- then we have a weird line damage = max(randint(18, 22), int(damage) + randint(-4, 4)). So it can never be less than 18. That's pretty high for weak chars.
Also I don't see where you control the amount of turns which the poison will work.

I didn't think 18 was a high number since normal health is at 100... Feel free to change it.

Turns are controlled here:

Code: [Select]
    class PoisonEvent(BE_Event):
        def __init__(self, target, source, effect):
            self.target = target
            self.source = source
            self.counter = 6 # We remove the event if counter reaches 0.
            self.effect = effect / 1000.0
            self.attributes = ['status', 'poison']

Event is created and added to the event handler. "counter" counts down to 0 and the event is terminated afterwards. I was actually thinking about rewriting BE in SimPy but that would have to be after the next release.

5) Healing:
- base amount of healed points is (effect + (char.intelligence + char.magic) * 0.25)*multiplier
It's sufficient for now, since we don't have many healing spells. In the future though I want to limit the power of weak spells, making high level ones much more useful for high levels.

Your call.
Title: Re: BE logic
Post by: DarkTl on November 11, 2015, 08:58:31 AM
I was actually thinking about rewriting BE in SimPy but that would have to be after the next release.
I see. Then advanced options will wait until then, I'll just balance existing ones since we can use them for calculations anyway.
Title: Re: BE logic
Post by: Xela on November 11, 2015, 09:25:50 AM
I see. Then advanced options will wait until then, I'll just balance existing ones since we can use them for calculations anyway.

Anything you can add will remain the same, SimPy may offer as a better loop/control over time, it doesn't have any effect on graphics or logic.
Title: Re: BE logic
Post by: DarkTl on November 12, 2015, 01:51:43 AM
What do you think about chance to hit?
Title: Re: BE logic
Post by: Xela on November 12, 2015, 02:06:42 AM
What do you think about chance to hit?

Dodging might be fun, definitely something to consider, should prolly be agility based, maybe some items as well.
Title: Re: BE logic
Post by: DarkTl on November 13, 2015, 06:41:30 AM
Wait a sec. Enemies never become poisoned. The poison damages them only once, without any noticeable messages in the battle log, like poison resist. Is it a bug?
Title: Re: BE logic
Post by: Xela on November 13, 2015, 01:40:39 PM
Wait a sec. Enemies never become poisoned. The poison damages them only once, without any noticeable messages in the battle log, like poison resist. Is it a bug?

If that is a fact, it is definitely a bug. I've coded poison to work as an attack on application and as an event executed before the target takes his/her turn. I have tested it thoroughly before pushing the code and it was working as intended, even when characters resisted poison logic and reports were still sound.

One thing to keep in mind is that Ren'Py is changing and evolving usually for the better. As I know it's inner code, I often use modules that are not "officiilally" exposed to developers and are subject to a change (however unlikely). So there is always a chance that my old code will not function as intended in modern Ren'Py, any issues that got to be fixed will take less then one line of rewriting to have them working again. I just need to know what is failing atm...
Title: Re: BE logic
Post by: DarkTl on November 14, 2015, 02:22:42 AM
I tested it via our single BasicPoisonSpell. It damages the target only once and never gives them damage over time. It is supposed to tell "%s not skilled enough to poison %s!" when failed, but it's not (especially since testing target couldn't possibly resist it with its stats).
Title: Re: BE logic
Post by: Xela on November 14, 2015, 03:11:32 AM
Well... it was working before :)

I'll take a look at it and the BE in general tonight, maybe run it through SimPy if that is possible. I need a short break from Jobs code.
Title: Re: BE logic
Post by: Xela on November 14, 2015, 05:08:31 AM
Ok, I've restored poison effects. I'll try to put some more time into coding in a few hours, gtg now.
Title: Re: BE logic
Post by: DarkTl on November 14, 2015, 01:06:05 PM
Mobs don't have a normalization, it's possible for them to have 0 stat, that sometimes forces the game to divide by zero without additional checks.
I suppose all stats should be at least 5 unless stated more in json.
Title: Re: BE logic
Post by: Xela on November 14, 2015, 02:06:45 PM
Which line of code is throwing the error. I can't see anything wrong with stats at 0...

I was busy again for the better part of the day, going to try and think a little bit if SimPy can help BE...
Title: Re: BE logic
Post by: DarkTl on November 14, 2015, 02:13:31 PM
Damage = attack/defence, for both weapons and magic. Also amount of turns for poison is (source.intelligence/target.constitution)+2.
Title: Re: BE logic
Post by: Xela on November 14, 2015, 02:20:44 PM
I was hoping for a line number/file or a line I can search for. We can add a check to prevent Zero division.
Title: Re: BE logic
Post by: DarkTl 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.
Title: Re: BE logic
Post by: Xela on November 14, 2015, 02:59:18 PM
Should be fixed.
Title: Re: BE logic
Post by: DarkTl 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.
Title: Re: BE logic
Post by: Xela 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?
Title: Re: BE logic
Post by: DarkTl 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  ::)
Title: Re: BE logic
Post by: Xela 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.
Title: Re: BE logic
Post by: DarkTl 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.
Title: Re: BE logic
Post by: DarkTl 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.
Title: Re: BE logic
Post by: Xela 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).
Title: Re: BE logic
Post by: DarkTl 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.
Title: Re: BE logic
Post by: Xela 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...
Title: Re: BE logic
Post by: Xela 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)...
Title: Re: BE logic
Post by: DarkTl on November 20, 2015, 08:41:23 AM
In my opinion, saving inside of BE is the worst form of save scamming.
Title: Re: BE logic
Post by: Xela 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.
Title: Re: BE logic
Post by: DarkTl 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.
Title: Re: BE logic
Post by: DarkTl on April 25, 2016, 04:43:57 AM
As for binding skills to weapons... It should be unique, unusual cases with powerful skills and rare weapons. We can't tie all skills to weapons, there should be general skills available with any weapon of some type.

At very least melee and ranged skills clearly should be different.
Title: Re: BE logic
Post by: DarkTl on April 25, 2016, 05:01:11 AM
One more thing, often we cannot control what kind of weapon will have battle sprite. Sometimes you should be glad you have found at least one decent battle sprite. And some sprites have no weapons, while others have swords, guns, bows, etc.

If we use unarmed attacks for everyone without equipped weapons, we'll have characters with swords who don't use swords. That's why we have basic attacks in characters jsons, they are based solely on sprites.

But what happens if a character with a sword attack will get a bow? Either we add BowAttack to attacks list, or replace SwordAttack with BowAttack. In the first case the character will have an advantage just because of sprite, in the latter case we again have a character with a sword who cannot use swords.

I'm not sure how to handle it.
Title: Re: BE logic
Post by: Xela on April 25, 2016, 06:55:51 AM
One more thing, often we cannot control what kind of weapon will have battle sprite. Sometimes you should be glad you have found at least one decent battle sprite. And some sprites have no weapons, while others have swords, guns, bows, etc.

If we use unarmed attacks for everyone without equipped weapons, we'll have characters with swords who don't use swords. That's why we have basic attacks in characters jsons, they are based solely on sprites.

I suppose they are based on unique character perception, which more often than not translates into art. I can imagine a character be sprite without a weapon but with corresponding weapon skill.

But what happens if a character with a sword attack will get a bow? Either we add BowAttack to attacks list, or replace SwordAttack with BowAttack. In the first case the character will have an advantage just because of sprite, in the latter case we again have a character with a sword who cannot use swords.

I'm not sure how to handle it.

I suppose we could add a "default_attack_skill" field to uchars, which if not false, will always be added to their list of battle skills. I can "if/else fork" cases where we equip a sword on someone who is already using the sword...

The problem with that approach is that such a character would be at advantage... by default, because his/her skill is better. I wonder if I can come up with an wrapper class to make default attack's stats generic somehow. I'll add this to front post and think about it before turning it into an issue on github.


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.

There is a lot of stuff I'd like to have in the future, but you can prolly do something along these lines right now...

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.
Yeah, it will work too. Either once per N days, or once per battle.

Hmm... it feels like we need some form of compromise here, maybe limiting weapons that can be equipped using base traits and making attacks more generic. I'd like a system which we can explain and remember what does what and why.
Title: Re: BE logic
Post by: Xela on April 26, 2016, 09:58:01 AM
I was thinking about what we can potentially do for normal attacks code-wise... it will be really hard to impossible to find gfx animations for all normal attacks:

['RodAttack', 'GunAttack', 'SprayAttack', 'ThrowAttack', 'BowAttack', 'SwordAttack', 'AxeAttack', 'KnifeAttack', 'CannonAttack', 'WhipAttack', 'CrossbowAttack', 'BiteAttack', 'FistAttack', 'ScytheAttack', 'ClawAttack']

Problems with creating GFX with code is that our sprites do not follow any specific design pattern, still we might be able to do some things by adding additional data to mob definitions. For example, alpha blending or masks can be used to:

- Cut images vertically, horizontally or diagonally and move the cuts apart.
- "Flash" the image.
- Change Alpha of the image.
- Use Zoom on image.
- Blend other patterns on the image (cuts/blood of different colors).

and etc.

I am not sure if this is something we should pursue but it is an option.
Title: Re: BE logic
Post by: DarkTl on April 26, 2016, 10:47:37 AM
It's not entirely true, our current animations for simple attacks just show a suitable sprite with quickly decreasing alpha, so we can add anti-material plasma cannons and still find an animation for their normal attacks (http://img1.liveinternet.ru/images/attach/c/4/122/469/122469273_vspuyshka28.png) without problems  :D
Now if you want better animations for normal attacks (they really don't look very impressive atm), then yeah, something should be done.
Title: Re: BE logic
Post by: Xela on April 26, 2016, 11:56:38 AM
It's not entirely true, our current animations for simple attacks just show a suitable sprite with quickly decreasing alpha, so we can add anti-material plasma cannons and still find an animation for their normal attacks (http://img1.liveinternet.ru/images/attach/c/4/122/469/122469273_vspuyshka28.png) without problems  :D

Well, it's like you've said yourself... we cannot release just with one attack per type so I thought we could (possibly) add levels to attacks (like Slash/Double Slash/Shadow Slash or something like that), problem is that we may not have enough decent animations to cover all of that...

Now if you want better animations for normal attacks (they really don't look very impressive atm), then yeah, something should be done.

So I was thinking... for example:

Sword:
- Slash (normal animation + slight shake effect to the defender if it hits).
- Double Slash (we show the animation twice rotated appropriately).
- Shadow Slash (attacker rushes towards defender and we show something like this: https://youtu.be/lDTjtXhKk9s). This kind of a setup may be just the code, without any drawn animations but the trouble is that there are sprites that will look ridiculous if we used that because they are holding huge weapons like bows/spears or wearing loose capes... that makes these kind of code driven effects to sprites semi-useless or at least very limiting...
Title: Re: BE logic
Post by: DarkTl on April 26, 2016, 12:12:45 PM
Even without shadow stuff there are many possible options with zoom, angles, alpha, masks + different numbers of sprites. Worth a shot.
Title: Re: BE logic
Post by: DarkTl on December 25, 2016, 03:44:19 AM
Unique BE skills from the final build of Eliont's Alkion Raiders:
- regeneration effect
- paralysis effect
- self protection from weapon attacks (knight class)
- ally protection from weapon attacks (knight class)
- enchanting ally weapon (+ elemental damage)
- blindness effect
Title: Re: BE logic
Post by: Xela on January 09, 2017, 09:34:48 AM
His classes are a lot more direct and specific...


What do we want from AI? I want to try to improve it, not all the way but at least make it a bit smarter than it is now... What should be considered most important? Right now I am trying to teach it to heal, revive and pick good skills but there are so many possibilities beyond stuff like this... we need to figure out how far we want to take it for beta.
Title: Re: BE logic
Post by: DarkTl on January 09, 2017, 12:43:38 PM
Well, main problems with the current random AI are:

- unlimited resources; as long as skills don't require health, AI is capable of spamming powerful attacks every turn. We don't have to limit mp and vitality - although it's an option too - but at least we could use a random cooldown for powerful skills, like 0-2 turns. As long as AI has less powerful skills too of course.

- selecting target; usually in games AI either goes for the most defenseless target or tries to take down the most dangerous target first.
In many games (including Alkion Raiders thanks to the knight class) player is capable to protect weaker party members with special skills which force AI to attack a well protected character instead, or simply taking the damage instead of the target.

- magical shields will be available for mobs too, they should know how to use them.
Title: Re: BE logic
Post by: Xela on January 09, 2017, 03:13:58 PM
- unlimited resources; as long as skills don't require health, AI is capable of spamming powerful attacks every turn. We don't have to limit mp and vitality - although it's an option too - but at least we could use a random cooldown for powerful skills, like 0-2 turns. As long as AI has less powerful skills too of course.

I believe that AI is not special in this case. There shouldn't be anything like unlimited resources.

- selecting target; usually in games AI either goes for the most defenseless target or tries to take down the most dangerous target first.
In many games (including Alkion Raiders thanks to the knight class) player is capable to protect weaker party members with special skills which force AI to attack a well protected character instead, or simply taking the damage instead of the target.

Noted.

- magical shields will be available for mobs too, they should know how to use them.

Buffs may be trickier but it's doable.
Title: Re: BE logic
Post by: DarkTl on January 10, 2017, 12:02:35 AM
I believe that AI is not special in this case. There shouldn't be anything like unlimited resources.
Then mobs are at risk of quickly spending all resources and then being limited to simplest attacks; or even waiting all the time if they don't have any simple attacks.
The middle ground is to have unlimited resources, but limited capability of using them. Or have limited resources, but make waiting also restore mp.
Title: Re: BE logic
Post by: Xela on January 10, 2017, 03:18:35 AM
Then mobs are at risk of quickly spending all resources and then being limited to simplest attacks; or even waiting all the time if they don't have any simple attacks.
The middle ground is to have unlimited resources, but limited capability of using them. Or have limited resources, but make waiting also restore mp.

I don't like unlimited resources for mobs, increase their capacity if you like. It's a good setup, they would have similar capabilities as normal players. There will be scripted fights at some point, like boss fights where the boss may restore everyone on their team after 7 turns (for example) except him/her/itself.
Title: Re: BE logic
Post by: DarkTl on January 10, 2017, 03:36:52 AM
It's a good setup, they would have similar capabilities as normal players.
As long as the player doesn't have access to items inside BE.
Title: Re: BE logic
Post by: Xela on January 10, 2017, 04:13:31 AM
As long as the player doesn't have access to items inside BE.

They don't atm, we can adjust if we decide to allow that at some point. Enemies would also be able to use items then.
Title: Re: BE logic
Post by: Xela on January 12, 2017, 04:47:47 PM
Oki, so a more complex AI will have to wait till post beta. Problem is that we do not have a separate method to calculate effect of any spell. Our method is causing sideeffects as it reports to log and passes around some data. I don't want to separate them right now so it'll have to wait. For now I've added reviving, healing, buffs and somewhat smarter attack skills choice. Everything runs on chance!

Plan is to add minor "tactics" (killing weakest/strongest enemy first) and maybe personality (like preference towards healing/reviving/attacking or maybe even specific kinds of spells).

There are also a couple of new (unrelated to BE) bugs that got to be traced down and squashed. I've started a new issue to keep track.
Title: Re: BE logic
Post by: DarkTl on January 13, 2017, 10:01:22 AM
If you want to calculate possible effects of spells to show AI which spell is the most effective considering elemental defences and stats, then it's cheating. AI shouldn't know about fire absorption or weakness until it casts at least one fire based spell.