Page 3 of 5
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 08 Apr 2010, 12:49
by Kage
Bertram wrote:Hi Kage,
Thanks to provide a bit of help.
From what you provided,
Code: Select all
newValue = (getModifiedAttribute(CHAR_ATTR_VITALITY)*30 + mLevel*10) >> 5;
I've made a tiny table to show average HP result for the first 20 levels:
HP-try.zip
Feel free to correct me if needed.
Yes, your table is incorrect... if you know what ">>" means... then you should had divided the file value by 32.
Code: Select all
newValue = (getModifiedAttribute(CHAR_ATTR_VITALITY)*30 + mLevel*10) >> 5;
is the same as
Code: Select all
HP = (VITALITY*30 + Level*10) / 32
Bertram wrote:
It seems to me that your HP formula gives an average 11% of the value from what the current HP formula gives.
Then, I guess both formulas are quite similar, in fact. With the fact that the current HP formula is scaled to fit the HP loss from physical attacks, if you don't mind, I'll keep the current formula for now.
Regarding Intelligence: Intelligence plays an important role in the magic system. It controls the spell recharge rate. This means the damage output of a magic user is directly proportional to its intelligence. But considering that magic has been dropped for CR1 I would suggest to wait with balancing any magic-related formulas until we made some real experience with the gameplay.
Ok, no problem. We're not in a hurry as long as the basics are fine.
Regarding the HP formula: Instead of adding hp-from-vitality and hp-from-level I would rather like to see a formula which multiplies them somehow so that you can't substitute one with the other.
Hmm. I had a try at this one:
Code: Select all
HP: (2+LOG(300*1 / Level) ) x 30 + 1.5 x Vitality x sqrt(Level)
This part: "(2+LOG(300*1 / Level) ) x 30" gives a hp boost especially for the ten first levels to avoid the "level 1, one hp" problem.
What's left is an HP scale based on a product more than an addition, as requested.
What do you think, Crush, Kage, anyone?
Best regards.
I would prefer to keep formulas as fast as possible, since they have to be recalculated regularly. sqrt() is quite resource intense.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 08 Apr 2010, 13:50
by Bertram
Hi Kage,
Yes, your table is incorrect... if you know what ">>" means... then you should had divided the file value by 32.
My table
is correct since the base value divided by 32, or bitwise right-shifted of 5 bits give the one results I've listed in the given file.
Then, my previous comment still apply, and I'd prefer keep the current formula for now, if you don't mind.
I would prefer to keep formulas as fast as possible, since they have to be recalculated regularly. sqrt() is quite resource intense.
Could the fast_sqrt() help here?
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 08 Apr 2010, 23:22
by Kage
Bertram wrote:
Could the fast_sqrt() help here?
I do not like the fast_sqrt() function, and do not approve of its usage.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 09 Apr 2010, 00:49
by Bertram
I do not like the fast_sqrt() function, and do not approve of its usage.
Care to develop your point a bit more?
Understand I cannot drop things because you simply don't like them.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 09 Apr 2010, 01:23
by Kage
Code: Select all
/*
* A very fast function to calculate the approximate inverse square root of a
* floating point value. For an explanation of the inverse squareroot function
* read:
* http://www.math.purdue.edu/~clomont/Math/Papers/2003/InvSqrt.pdf
*
* Unfortunately the original creator of this function seems to be unknown.
*
* I wholeheartedly disagree with the use of this function -- silene
*/
float fastInvSqrt(float x)
{
typedef char float_must_be_32_bits[(sizeof(float) == 4) * 2 - 1];
float xhalf = 0.5f * x;
uint32_t i;
memcpy(&i, &x, 4);
i = 0x5f375a86 - (i >> 1);
memcpy(&x, &i, 4);
x = x * (1.5f-xhalf * x * x);
return x;
}
Four reasons:
A. I don't understand how the code works
B. It looks ugly
C. I tried using it before, and the use of it caused me many headaches
D. Silene is a better programmer then me, and while I have never meet him, I have worked on code he wrote, and I have a great deal of respect for him. He disagrees with its use and he knows more then me about the subject. So I just have to trust him when he says its not a good idea to use the function, the same way I would trust a doctor about a medical decision I am not well informed enough about.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 09 Apr 2010, 06:53
by Rotonen
Only two major problems with fast_sqrt(): 1) 32bit specific, 2) a tad bit inaccurate.
As for using sqrt() for a base formula, evaluating at this point the impact on performance it will have is rather meaningless. It too is a tad bit inaccurate, a bit less than fast_sqrt(), though.
Back to topic, which is gamesystem design, please.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 09 Apr 2010, 09:15
by Bertram
Thanks Rotonen,
This topic represents the most relevant questions left:
http://forums.themanaworld.org/viewtopi ... 240#p87240
Plus, what do you think of the value and variables influence of this HP formua, sqrt() problem apart?
Code: Select all
HP: (2+LOG(300*1 / Level) ) x 30 + 1.5 x Vitality x sqrt(Level)
This part: "(2+LOG(300*1 / Level) ) x 30" gives a hp boost especially for the ten first levels to avoid the "level 1, one hp" problem.
What's left is an HP scale based on a product more than an addition, as requested.
Best regards.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 12 Apr 2010, 23:00
by Bertram
No comments so far?
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 12 Apr 2010, 23:44
by Rotonen
Posting tables works better.
A simple lvl x vit table should do.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 13 Apr 2010, 10:16
by Bertram
I'll post a new sheet when there is something new to bring.
Latest points left:
- The special damages haven't been discussed also, or I missed something.
- Should we keep the Hit Per Second original formula or the one from Rotonen?
Code:
Code: Select all
Hit Per Second (Current): Hits per second: (1 + Agility / 100) * WeaponSpeedFactor
Hit Per Second (Rotonen): Hits per second: (0.3 + (Agility * 3) / 100) * WeaponSpeedFactor
I'll edit this post or make a new one with another hp formula asap, something more simple alla vit x lvl x ratio.
Thanks for your comments.
Regards.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 13 Apr 2010, 13:16
by Crush
For programming it would be better to define the attack speed formulas as the number of game ticks between two attacks (10 game ticks is one second).
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 14 Apr 2010, 14:10
by Bertram
For programming it would be better to define the attack speed formulas as the number of game ticks between two attacks (10 game ticks is one second).
That can be done:
So far, we've got Hit per second (HpS). To translate them in ticks (=100ms for the ManaServ), we can do:
HpS x 100 / 1000 or HpS / 10.
To get the number of ticks before a new attack, you then do: 1/ the above result.
Example:
Hit Per Second : 4.
4 /10 = 0.4
1/0.4 = 2.5. 1 hit every 2.5 ticks. (Actually, with the current system, the player would do a hit on tick 3 and tick 5 in that case.)
Then; the current HpS formulas would become:
Technical note: The formula should be coded against a TICKS_PER_SECOND const to keep relevancy and we should remove the 100 hardcoded value to make use of this const in line 73 of src/game-server/main-game.cpp, IMHO.
Code: Select all
Ticks before Hit (Current): 1 / ((1 + Agility / 100) * WeaponSpeedFactor) / TICKS_PER_SECOND)
Ticks before Hit (Rotonen): 1/ ((0.3 + (Agility * 3) / 100) * WeaponSpeedFactor) / TICKS_PER_SECOND)
Anyway, we still have to know which one of the two you prefer. I'm for the Rotonen's one, since the player would feel more the battle speed increase of its character, than for the first one.
Regarding HP, nothing good went up from something like: vit x level x something for me.
Kage's formula (with a scale of 9.09 to fit the other formulas) could still be used if you really want to but it's also a vit + level one, just like the first proposed ones. So if someone has got a better idea, I'll be glad to have a look at it.
Regards.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 19 Apr 2010, 07:46
by Bertram
Hi again,
To get things a bit up, I'd say that if I get no 'DON'T DO THAT' with following proper reasons within the next week, I'll upgrade the mana-stats.xls file with the Hit Per Second from Rotonen, and the latest max HP found formula, based on the fact that it's realistic to say that 'max HP' won't be recalculated every ticks
:
Code: Select all
Hit Per Second (Rotonen): Hits per second: (0.3 + (Agility * 3) / 100) * WeaponSpeedFactor
Ticks before Hit (Rotonen): 1/ ((0.3 + (Agility * 3) / 100) * WeaponSpeedFactor) / TICKS_PER_SECOND)
Code: Select all
HP: (2+LOG(300*1 / Level) ) x 30 + 1.5 x Vitality x sqrt(Level)
As for the special damages. Crush said so far, that they should be multiples of normal damages.
I'm ok with this principle. Now, if we imagine giving the character one special (to start with, or more?) like the big sword slash we saw in the playerset development, should it be 1.3, 1.5, 2.0 x the normal damages?
Best regards.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 19 Apr 2010, 10:58
by Crush
All stats are recalculated whenever an attribute changes. This can happen quite frequently in some situations.
Divisions, calculating square roots and logarithms are VERY expensive to compute. Please, when there is ANY reasonable way to design the formulas without then please do so. When you want to fix the "one hp on level 1" problem wouldn't it be possible to just add a fixed value of, let's say, 50 hp to the total?
But nevertheless: all these formulas will be quite easy to change even during the beta test.
Re: [WIP] Gameplay design and balancing - CR1 - Freeyorp
Posted: 19 Apr 2010, 14:32
by Rotonen
For now, Let's just take the appropriate curve providing formulas and proceed into testing when our content allows this.
Retouching formulas between future CRs is not out of the question, but undesirable, of course.