ValyriaTear / ValyriaTear

Open Source J-RPG (Based on the Hero of Allacrost engine)
http://valyriatear.blogspot.com/
Other
224 stars 66 forks source link

Half-Episode I release - Balancing Discussion #30

Closed rootslinux closed 11 years ago

rootslinux commented 11 years ago

I'm making this thread so that we can discuss balance issues in the current release candidate.

I'll start by sharing my thoughts on where we need to go based on my own experiences. I haven't played the game the whole way through yet. My characters are on level 4 and I have gotten to the wolf boss, but I haven't been able to beat him so I'm stuck for now. Here's where I think improvements should be made:


That's all that I want to focus on for now. I just want to think about what needs to change in terms of stats/numbers. There are other balance issues to consider as well, such as whether items are effective/abundant enough, whether some skills need to be made more useful, etc. But let's tackle this one piece at a time. :)

I'm going to be doing some background research today into how to properly do balancing. I don't want to just play around with numbers until we find something that "sorta works". I think we may need to employ spreadsheets or perhaps write some scripts to do some number crunching.

Bertram25 commented 11 years ago

Hi, :)

Thanks for opening this issue.

I agree just about everything you've put here. Just to give hints about my own opinion:

If we can have all that represented in a spreadsheet somehow, we'll be able to create balances monsters stats without any big troubles, IMHO.

Feel free to tell me if you need more help in one of those areas, or to keep up the discussion about it.

rootslinux commented 11 years ago
rootslinux commented 11 years ago

I finally beat the wolf boss tonight after playing with his stats. I tried lowering his defense ratings slightly hoping that would do it, but after 3 tries fighting him at full health, he still walloped my party and I exhausted all of my potions. I changed his hit points from 320 to 120 and that was a much more reasonable fight. I still had to use potions and it was still a challenge, but a much more reasonable one. However I died again a couple maps later as that freaking snake kicked my ass with the slow and sleep status he inflicted. I managed to survive that battle, but lost Kayla and got taken out in the next fight that I couldn't avoid.

Here are some more balance issues I would like to address:

1) Health potions don't heal enough IMO. 40 HP is not that much, and even at level 1 that won't fully heal a character I think. I want to boost it to 60 HP for now. Later I'd prefer if the HP healed was a slight range. In Allacrost, we plan for potions/spells to heal in two different ways. The first is healing a fixed amount. The second is to heal a percentage of a character's maximum HP. Example: Character X has 1,200 HP. A basic potion will heal the maximum value of: 50 HP or 20% of a character's max HP (240 HP in this example). Allacrost does this so that items don't become entirely useless in the later stages of the game (healing only 50HP of a 1,200 HP character doesn't do much).

2) Bronann's second skill needs improvement. It actually seems worse/weaker than his initial skill. I want to change it so that it deals more damage (say, 1.5-2.5 of the basic skill damage) and remove the property of the skill that makes it more likely to miss.

3) I think both Bronann's and Layla's initial skills should target actors, not specific points. It's the first skill in the game, and I feel that it would be better to introduce the player to the concept of attack points at a later time (with the 2nd or 3rd attack skill that they learn).

4) The defense stance skill needs improvement. It's really not worth using at all right now (even in the boss battle). I think it could use some or all of the following: increase defense bonus intensity by two levels -or- skill targets entire party -or- also gives a very minor boost to agility (haste). Not sure of the best way to change it right now, so looking for input here. I also think that only Kalya should learn this skill, not Bronann as well.

5) I feel like there needs to be another save point/healing spring somewhere after the first boss fight. I was feeling lost and hopeless as I sprinted around the maps dodging enemies trying to find one. I didn't find one, and I died and lost all of that progress :(

6) I feel like the snake enemy is a bit too tough right now. It took a lot of hits to bring him down (my characters were on level 5), and all the while he was really hurting my party with all his status effects. So I vote for lowering his HP a bit so he's not such a tank. I like his ability to put characters to sleep, but I think his agility slow status should either be removed or it's chance to take effect reduced drastically. Having all that agility slow status stack on both characters was brutal.

Let me know what you think about all that.

Bertram25 commented 11 years ago

Hi again :)

The only good use I can think of spreadsheets right now is to just see all of the character stats for each level and do a gut check to make sure nothing looks wrong (ie attack power suddenly rising exponentially after level 12). I don't know what else could be done in a spreadsheet to be honest, other than some simple formulas to compare the stats of one character or enemy versus another.

Let's start with that. I guess it'll help to guide a bit the rest.

Not sure I agree with you there. If XP/drunes were set based on a single formula, I'd find that pretty boring. There would be no enemies that you would seek out that you know offer high amounts of XP or drunes dropped.

Ah, I guess I must explain myself a bit more. If we can find a formula that tell us: "Hey, here is the average amount of XP drunes that bad guys is worth." We can use it as a base to know whether we're giving too much or not enough. Yet, I see all this only as a helper, not a rule. The actual values will have to be shaped by hand, indeed.

I completely agree. We should balance the enemy stats around the character stats, not vice versa. And we should try to get the character stats balanced correctly as soon as possible, because any later changes to those will affect balance of early game enemies and XP levels.

Hence the spreadsheet about at least that would be good, IMHO.

Good point. I think about 10 battles would be sufficient to gain the first XP level. We need to decide on the rate of growth in XP required to reach the next level, and things should balance itself after that. I feel growth should be exponential, not linear. In other words XP required shouldn't change from "x" to "x + y" between two levels, but rather from "x" to "x * y" or "x ^ y". I'll fiddle around with XP growth formulas and propose some once I've looked at the math. Do you agree that 10 is a decent number of battles for the first level up and that XP growth rate should be exponential in nature?

I completely agree about the exponential nature of next level XP. About the 10 times required, in itself it is fine, but it'll also depend on what you think about this, IMHO:

I also like that the characters are weak at level 1. I want them to remain weak, but not so weak that the party is on the verge of death after a single battle.

Sure, np.

1) Health potions don't heal enough IMO. 40 HP is not that much, and even at level 1 that won't fully heal a character I think. I want to boost it to 60 HP for now. Later I'd prefer if the HP healed was a slight range. In Allacrost, we plan for potions/spells to heal in two different ways. The first is healing a fixed amount. The second is to heal a percentage of a character's maximum HP. Example: Character X has 1,200 HP. A basic potion will heal the maximum value of: 50 HP or 20% of a character's max HP (240 HP in this example). Allacrost does this so that items don't become entirely useless in the later stages of the game (healing only 50HP of a 1,200 HP character doesn't do much).

The reasoning is indeed valid. Go ahead at increasing to 60HP for now. As for the rest, I'd like the fact that items give a bit less in battles than in field (in the menu mode.) because of the rush of the action.

2) Bronann's second skill needs improvement. It actually seems worse/weaker than his initial skill. I want to change it so that it deals more damage (say, 1.5-2.5 of the basic skill damage) and remove the property of the skill that makes it more likely to miss.

Completely agree. I noticed that several times and it is also bugging me but I hadn't the time yet to go at fixing this.

3) I think both Bronann's and Layla's initial skills should target actors, not specific points. It's the first skill in the game, and I feel that it would be better to introduce the player to the concept of attack points at a later time (with the 2nd or 3rd attack skill that they learn).

Good point! Very smart fact that the one of introducing battle feature little by little. :) Yet, I wonder how the defense is computed in that case. I know that the BattleCharacter::TotalDefense() is misnamed for instance as it should be called GetAverageDefense() since it's what's it is actually returning

4) The defense stance skill needs improvement. It's really not worth using at all right now (even in the boss battle). I think it could use some or all of the following: increase defense bonus intensity by two levels -or- skill targets entire party -or- also gives a very minor boost to agility (haste). Not sure of the best way to change it right now, so looking for input here. I also think that only Kalya should learn this skill, not Bronann as well.

Kalya only to learn it <-- ok for me, indeed more logical concerning her profile. The defensive stance will then need to not be self targeted anymore IIRC.

skill targets entire party <-- Warning: Not implemented engine wise. And we should find a way to prevent yet another new button for that, if possible. So, I'd say: target: one ALLY (copes well with the skill name btw), and increase the defence by two. As for the haste, I shall keep it for a bit later (I've created the haste spell already)

5) I feel like there needs to be another save point/healing spring somewhere after the first boss fight. I was feeling lost and hopeless as I sprinted around the maps dodging enemies trying to find one. I didn't find one, and I died and lost all of that progress :(

Shirish also complained about that several times and even if the first dungeon shape didn't make that relevant in our own humble opinion, I suppose you both are right after all, and now the dungeon is getting close to an end. I shall then add a save point anytime soon in the map after the first wolf encounter for now. Speaking about the wolf, the two characters will have to fight it three times. Each time a bit harder than previoulsy, and the last time until coma for it. (if it can help balance it) IMHO, the first time, the wolf should flee (even if as now it will have a die sequence) at something about the third of its total HP, the next time, the half of two/third and the last time with full potential.

6) I feel like the snake enemy is a bit too tough right now. It took a lot of hits to bring him down (my characters were on level 5), and all the while he was really hurting my party with all his status effects. So I vote for lowering his HP a bit so he's not such a tank. I like his ability to put characters to sleep, but I think his agility slow status should either be removed or it's chance to take effect reduced drastically. Having all that agility slow status stack on both characters was brutal.

So the effect was kinda obtained ;> Yet, you're right. Please do not remove them but reduce both snakes' HP and agility (so they will attack less often) and feel free to reduce the chance of the ability or their duration if needed. Same comments go for the bats and the slime mother in the cave. Please don't remove their abilities, but feel free to tune them to be weaker if needed.

Thanks a lot for all those smart thoughts about balancing and best regards,

rootslinux commented 11 years ago

If ten battles are required against let's say three equivalent enemies, how many battles would you require at level 50 to reach level 51 against three equivalently strong enemies?

I'm not sure. Probably a little more than 10 (15? 20?) because I feel like higher levels should take a bit longer to reach than the initial levels provided you are facing the same relatively equivalent enemies. But I have no strong opinion on this matter.

I remember you're using a gaussian function: https://github.com/Bertram25/ValyriaTear/blob/master/src/common/global/global_actors.cpp#L1088

Yeah, that's a really lazy formula I wrote to just have something in the last Allacrost release. It's bad. The reason that the Guassian function is in there is to provide a slight amount of variation so that every character doesn't always level at exactly the same time (eg level 5 is reached at 1,234 XP for each character). If you don't want any of that randomization in there, that's fine with me.

The reasoning is indeed valid. Go ahead at increasing to 60HP for now. As for the rest, I'd like the fact that items give a bit less in battles than in field (in the menu mode.) because of the rush of the action.

Already done in my branch. And the field use heals 65 HP. Maybe it should heal a little more than than?

Completely agree. I noticed that several times and it is also bugging me but I hadn't the time yet to go at fixing this.

Changed in my branch as well. I removed the additional evasion chance from the skill (there was a 5% additional chance it would miss over the sword slash) and changed the damage calculation from "CalculatePhysicalDamageAdder(user, target, 0, 0.5" to "CalculatePhysicalDamageMultiplier(user, target, 1.75)". I love the new skill, and you can tell it is much more powerful without being a one-hit kill manoeuvre. If you look at the previous damage formula, it actually didn't increase the damage at all (it added 0 to standard damage). It just set a more narrow standard distribution curve for the range of possible damages.

Good point! Very smart fact that the one of introducing battle feature little by little. :) Yet, I wonder how the defense is computed in that case. I know that the BattleCharacter::TotalDefense() is misnamed for instance as it should be called GetAverageDefense() since it's what's it is actually returning

Yeah that should be renamed. I changed both initial attack skills in the code. I left Bronnan's second attack skill the same (it still attacks specific points). I'm not sure if we want to change that one to just a foe target as well.

Kalya only to learn it <-- ok for me, indeed more logical concerning her profile.

Got it. I'll increase the defense effect, set it to target an ally, and not add any haste effect.

Yet, you're right. Please do not remove them but reduce both snakes' HP and agility

Don't worry, i will not remove any enemies you put in. I'll tweak the snake stats like you suggested until he feels stronger than the slime/spider, but not too strong. The sooner you put in a save point into the map, the easier it will be for me to balance things correctly. I feel like we're going to have to add some debug-mode "cheats" to make balancing easier. For example: allowing save anywhere or infinite stamina so I can easily run from one area to the next. ;) Would be nice to have, but it can come later as I should be fine for now.

Thanks for the feedback and I'm glad we agree on nearly all of these changes. :)

rootslinux commented 11 years ago

https://docs.google.com/spreadsheet/ccc?key=0AqBUVoSDHKhkdG1lTkJPYlVLZ0dHZ0VDSXVTbi1MQ3c

I started working on a spreadsheet tonight. It is publicly available at the link above.

XP growth: I threw out the current XP growth formula (because I know it will never work) and tried a simple exponential formula instead (new = old ^ 1.025). It sort of works okay, but the growth amount changes too little at the low levels and too high at the higher levels. I ran it from levels 1-50 as you can see. I think what we may need to try is something like (new = old ^ 1.01 + 50 * xp_level). With that formula, the change would be increased mostly by the 50 * xp_level in lower levels, then in higher levels the old ^ 1.01 would account for most of the growth and the 50 * xp_level wouldn't matter as much. I'll have to keep playing around with formulas to find one that looks like it "works".

Another alternative is to just make a strict growth table. Instead of using a formula, why not create our own numbers for how much XP it takes to gain each new level for each character? I'm having trouble justifying why we would want to rely on a single formula.

One thing that I'd like to figure out in google spreadsheet (I'm not knowledgeable with spreadsheet apps) is to find a way where I can have a list of formulas on one page that I can easily select from and plug in to the data set. I'll probably just keep doing it the hard way though because I don't want to spend time searching for a way to do that.

Stats growth: I only grew the stats out to level 15, as that's the max level of the release. Currently stats growth works by defining a value for each stat to increase on each level. You don't have to define an entirely new set of growth for each level, as if there is none defined for a given level, it will use the previous growth values.

Currently I just plugged in the growth tables that are already used in the game. There are two growth tables: one that takes place at XP level 1 and up, and another that takes place at XP level 6 and up. I'm not sure how many growth tables we want to have for this release (the number can be between 1 and 15). Or if we want stat growth to not be an additional formula but something else (for example new stat = old stat * 1.1 + xp_level / 4). I think just adding numbers to stats should be fine, and gives us more control over how characters grow than if we were to define a growth formula for each (which could be very difficult to balance).

The current growth stats do need to be changed though. The characters should be more divergent in their growth (Bronann gains more HP and strength, Kayla gains more SP and agility, for instance). The characters should feel unique with their own strengths and weaknesses IMO.

And as for the higher level growth stats (beyond level 15), I think we don't need to worry about that right now as long as we continue to use simple additions to stat values between levels. Those can be added, tweaked, and balanced later in the game, and the enemies found later can be balanced to account for whatever that type of growth is.


Okay, so to summarize we need to address the following questions:

1) Should we use a formula for calculating XP to next level, or just hand-make a table with these values?

2) Do we want stat growth to be simply additive (we just add a pre-set number on to each stat), or do we want a more complex method for growing these stats?

3) How often do we want to change the stat growth table for the characters? Every level? Every other level? Every 5 levels?

4) In what direction do we want each character to grow? How much should their various stats increase so that they grow to have different strengths and weaknesses in their abilities?

I think that's enough for now.

rootslinux commented 11 years ago

I've created a branch with my balancing changes that you can view at the link below. I don't know if you want this branch uploaded to your repository or if we should just keep it in mine. I'll submit a pull request once I've done a complete playthrough and I feel comfortable with the state of balancing (although more playthroughs and tweaks may follow later).

https://github.com/rootslinux/ValyriaTear/tree/balancing

Side note; I've noticed that for skills that inflict a status, you calculate a custom duration time for each one. For example:

            local effect_duration = user:GetVigor() * 2000;
            if (effect_duration < 15000) then effect_duration = 15000 end
            target_actor:RegisterStatusChange(hoa_global.GameGlobal.GLOBAL_STATUS_AGILITY_LOWER,
                                              hoa_global.GameGlobal.GLOBAL_INTENSITY_POS_GREATER,
                                              effect_duration);

I disagree with this design for two reasons. First, you make the status effect last longer for more powerful characters, which seems kind of counter intuitive. It's like a punishment for having a high stat rating. Second, there is no way to convey to the player how long status effects will last if they all have a custom duration. The player doesn't know if that status is going to naturally disappear after 5 seconds or 50, and so they can not make an informed decision about whether or not they should address it (by curing the status affliction). I'd find this pretty frustrating as a player.

If this is how you want to do things, that's fine. But I thought I'd make you aware of this issue. In Allacrost, I always intended status effects to last the same amount of time across all effects and intensities (ie, status effects will automatically lower in intensity after 45 seconds). But it's fine if you want to deviate from that design and make status effects act differently in VT. :)

Bertram25 commented 11 years ago

Hi @rootslinux And thanks for the thorough work on this. :)

I guess it's the tenth time I've reading what you wrote to try to "balance" my own thoughts before giving my opinion:

1) Should we use a formula for calculating XP to next level, or just hand-make a table with these values?

Curiously, by what I heard at the time I was giving a hand in doing translations mostly of snes, megadrive/genesis, game boy advance, ... games to other languages, I heard several times that the games were using a fixed tables, with the exception of FF tactics IIRC, and linking this with what one of my math professor was saying, I'd say this:

I guess the table and the functions we might choose are linked and we would have to go from one to another to find out about which one is best. IMO, a well-chosen function can help us fixing base values, yet to find the "perfect" function for our need, we'll need to set not-so-roughly the points we want to see for each level, and then find a function that corresponds the most to those points.

I'd thus go with the table option, as it's the most direct way to check the values chosen, I guess. It also have the quality to let us refine a certain sub-set of values if it appears later to be needed, while not to find yet another formulae for that. After all, a lot commercial RPGs out there do it.

2) Do we want stat growth to be simply additive (we just add a pre-set number on to each stat), or do we want a more complex method for growing these stats?

IMHO, a formula here would be cumbersome. The way you chose to simply tweak the numbers added is quite simple and smart and doesn't need to be more evolved than that. Again, a formula can help in putting the base values that can be tweaked afterwards. Again IMO.

3) How often do we want to change the stat growth table for the characters? Every level? Every other level? Every 5 levels?

I actually thought about it since the beginning of this year, without having much time or content to focus on it efficiently. I would have used something like every 7 levels, just not to use something 10 multiple based. But it also depends on my answer below.

4) In what direction do we want each character to grow? How much should their various stats increase so that they grow to have different strengths and weaknesses in their abilities?

All those questions are linked to the same vision we have to finish building here I guess. IMHO, and with a little bit of fortunate and unfortunate earlier experiments here, we should have a clear vision of the stats we want each character to have at level 25, 50, 75 and 100 (which I guess will be the max level.) [Side note: I even thought to set it up to 101, as some kind of nag to other RPGs. ;)]. Once that is done, the scaling what's in between will be much more easy. Very first question, what would be (roughly) the max value that we should tend to? Should make each character tends the most to the max for one of their stats, and less for the others? E.g.: Kalya would have almost the highest in Protection, Bronann in Vigor, Sylve in Agility, and Thanis in Strength, at level 100?

And as for the higher level growth stats (beyond level 15), I think we don't need to worry about that right now as long as we continue to use simple additions to stat values between levels. Those can be added, tweaked, and balanced later in the game, and the enemies found later can be balanced to account for whatever that type of growth is.

About that I'd say that it is true if we go using a table, but rather risky if we go using a formula, which thus would have to be tested against the highest level limit.

Anyway, I do think you have something well started.

Best regards,

Bertram25 commented 11 years ago

I remember you're using a gaussian function: https://github.com/Bertram25/ValyriaTear/blob/master/src/common/global/global_actors.cpp#L1088

Yeah, that's a really lazy formula I wrote to just have something in the last Allacrost release. It's bad. The reason that the Guassian function is in there is to provide a slight amount of variation so that every character doesn't always level at exactly the same time (eg level 5 is reached at 1,234 XP for each character). If you don't want any of that randomization in there, that's fine with me.

I like the randomization here pretty much in fact. :) Simply because that makes it unpredictable for the player, avoiding him/her to bother about it, since it "seems" complicated, unconsciously making them focus more on other game elements, or something like that. ;)

The reasoning is indeed valid. Go ahead at increasing to 60HP for now. As for the rest, I'd like the fact that items give a bit less in battles than in field (in the menu mode.) because of the rush of the action.

Already done in my branch. And the field use heals 65 HP. Maybe it should heal a little more than than?

I'd say about 20% more, to make it worth using off battles, rounding the numbers to look more polished, I'd say 70 HP?

Completely agree. I noticed that several times and it is also bugging me but I hadn't the time yet to go at fixing this.

Changed in my branch as well. I removed the additional evasion chance from the skill (there was a 5% additional chance it would miss over the sword slash) and changed the damage calculation from "CalculatePhysicalDamageAdder(user, target, 0, 0.5" to "CalculatePhysicalDamageMultiplier(user, target, 1.75)". I love the new skill, and you can tell it is much more powerful without being a one-hit kill manoeuvre. If you look at the previous damage formula, it actually didn't increase the damage at all (it added 0 to standard damage). It just set a more narrow standard distribution curve for the range of possible damages.

Perfect! :)

Good point! Very smart fact that the one of introducing battle feature little by little. :) Yet, I wonder how the defense is computed in that case. I know that the BattleCharacter::TotalDefense() is misnamed for instance as it should be called GetAverageDefense() since it's what's it is actually returning

Yeah that should be renamed. I changed both initial attack skills in the code. I left Bronnan's second attack skill the same (it still attacks specific points). I'm not sure if we want to change that one to just a foe target as well.

Hmm, I think you can let it to attack point. The player has fought enough at that level, to get to know about attack points without being overwhelmed by the information. As a player myself, once I noticed my new skill attack specific points on enemies, I would try it out on each one of the dungeon to see whether it's worth it. Maybe we can play with that? Also, I didn't re-read the skill description but maybe we should tweak it ?

Thanks for the feedback and I'm glad we agree on nearly all of these changes. :)

Agree or not, I do appreciate the thorough and constructive comments you've brought so far. Please keep it up. :)

Bertram25 commented 11 years ago

I've created a branch with my balancing changes that you can view at the link below. I don't know if you want this branch uploaded to your repository or if we should just keep it in mine. I'll submit a pull request once I've done a complete playthrough and I feel comfortable with the state of balancing (although more playthroughs and tweaks may follow later).

Np, let's exactly do that. just try to rebase when you pull: git pull --rebase git://github.com/Bertram25/ValyriaTear.git

as it will put all your unmerged commits on top of the history and prevent the creation of merge points that will make noise when you'll make a merge request. Plus, it's easier to review them for me. :)

I disagree with this design for two reasons. First, you make the status effect last longer for more powerful characters, which seems kind of counter intuitive. It's like a punishment for having a high stat rating. Second, there is no way to convey to the player how long status effects will last if they all have a custom duration. The player doesn't know if that status is going to naturally disappear after 5 seconds or 50, and so they can not make an informed decision about whether or not they should address it (by curing the status affliction). I'd find this pretty frustrating as a player.

I can understand you disagree about it, and I sincerely see why. Using a fixed duration is a fine way to avoid the problem of balancing it. Now, variations in the effect duration is something I want to see happen, even if the formulae used there are starters, and certainly not something finely tuned.

As for the game play, putting a longer bad effect on a monster because I'm stronger is not a punishment for me, but rather something I expect as a player, and something I'd play with. Hence, I see no frustration here. I'd definitely increase the effect if you're stronger than the enemies, but not last too long, and make it shorter if you're weaker.

Now, conveying the duration of the effect to the player is something I wouldn't do since the player shouldn't be aware of that, but rather hoping it to last the longest possible when positive for him. If you knock out somebody (don't test that ;]) you can't tell how much time he will stay unconscious, right? You'd just expect it will last longer if you hit harder, right?

Good effects also shouldn't last too long when put on self, even If I do think they should last longer as your stats grow up. Same thought about enemies.

As a conclusion, yes, I want to see custom duration for status effects. the balancing issue I see about that is min/max of the effect duration that should be carefully tested. Note also that the battle speed factor depending on the battle mode makes them potentially shorter. Thus, any effects should tested in the slowest and quickest modes to make sure.

csolisr commented 11 years ago

As an old user of the RPG Maker line (I've tested 2003, XP, VX) I can ascertain that the level-up experience values and status improvements were made with internal configurable tables. I allude they give more flexibility to tweak than a fixed formula, our that they're easier to build than an algorithm.

Yohann Ferreira notifications@github.com escribió:

Hi @rootslinux And thanks for the thorough work on this. :)

I guess it's the tenth time I've reading what you wrote to try to "balance" my own thoughts before giving my opinion:

1) Should we use a formula for calculating XP to next level, or just hand-make a table with these values?

Curiously, by what I heard at the time I was giving a hand in doing translations mostly of snes, megadrive/genesis, game boy advance, ... games to other languages, I heard several times that the games were using a fixed tables, with the exception of FF tactics IIRC, and linking this with what one of my math professor was saying, I'd say this:

I guess the table and the functions we might choose are linked and we would have to go from one to another to find out about which one is best. IMO, a well-chosen function can help us fixing base values, yet to find the "perfect" function for our need, we'll need to set not-so-roughly the points we want to see for each level, and then find a function that corresponds the most to those points.

I'd thus go with the table option, as it's the most direct way to check the values chosen, I guess. It also have the quality to let us refine a certain sub-set of values if it appears later to be needed, while not to find yet another formulae for that. After all, a lot commercial RPGs out there do it.

2) Do we want stat growth to be simply additive (we just add a pre-set number on to each stat), or do we want a more complex method for growing these stats?

IMHO, a formula here would be cumbersome. The way you chose to simply tweak the numbers added is quite simple and smart and doesn't need to be more evolved than that. Again, a formula can help in putting the base values that can be tweaked afterwards. Again IMO.

3) How often do we want to change the stat growth table for the characters? Every level? Every other level? Every 5 levels?

I actually thought about it since the beginning of this year, without having much time or content to focus on it efficiently. I would have used something like every 7 levels, just not to use something 10 multiple based. But it also depends on my answer below.

4) In what direction do we want each character to grow? How much should their various stats increase so that they grow to have different strengths and weaknesses in their abilities?

All those questions are linked to the same vision we have to finish building here I guess. IMHO, and with a little bit of fortunate and unfortunate earlier experiments here, we should have a clear vision of the stats we want each character to have at level 25, 50, 75 and 100 (which I guess will be the max level.) [Side note: I even thought to set it up to 101, as some kind of nag to other RPGs. ;)]. Once that is done, the scaling what's in between will be much more easy. Very first question, what would be (roughly) the max value that we should tend to? Should make each character tends the most to the max for one of their stats, and less for the others? E.g.: Kalya would have almost the highest in Protection, Bronann in Vigor, Sylve in Agility, and Thanis in Strength, at level 100?


Reply to this email directly or view it on GitHub: https://github.com/Bertram25/ValyriaTear/issues/30#issuecomment-10281007

  • Carlos Solís
Bertram25 commented 11 years ago

@csolisr : Ah thanks for pointing out, it's always good to know.

rootslinux commented 11 years ago

Phew, there's a lot to respond to. I generally agree with everything you said. So let me see if I can summarize here:

1) Should we use a formula for calculating XP to next level, or just hand-make a table with these values?

We'll use a custom data table rather than a formula. This will allow us to adjust each data point as we need to in the future. To populate the table, we'll use a formula as a starting point and tweak the numbers from there. We will also apply a slight amount of variation with a Gaussian function to the raw data table number so that they aren't always the same.

2) Do we want stat growth to be simply additive (we just add a pre-set number on to each stat), or do we want a more complex method for growing these stats?

We'll leave stat growth the way that it is now. Stats grow via additive data tables, and the stat growth values can change (or stay the same) at any level that we choose.

3) How often do we want to change the stat growth table for the characters? Every level? Every other level? Every 5 levels?

Undecided. Sounds like 7 levels.

4) In what direction do we want each character to grow? How much should their various stats increase so that they grow to have different strengths and weaknesses in their abilities?

Adjust stats so that they meet "milestone" goals of how we want the characters to look at at various levels (25, 50, 75, 100).

And other notes:

Bertram25 commented 11 years ago

That sums it up quite prettily.

rootslinux commented 11 years ago

By the way, I really need you to add that second save point/healing shrine/whatever before the cave. I will not continue any of my balancing work until you do. I spent another half hour playing yesterday, got all the way to the cave, then Kayla died and I wasn't able to survive as I tried to run all the way back to the save point at the beginning. I can't work on balancing this game if I keep losing so much time testing because there are not enough areas to save my progress.

On another note, maybe there could be an event triggered near the cave entrance that allows you to travel back to the beginning of the forest quickly? (Ie, an event where a tree falls, opening up a new path). I know that's not simple to do because it's an event that would affect two maps, but it would be pretty darn nice. Especially since you can also go back to the shop and buy any extra potions you need before the cave.

Bertram25 commented 11 years ago

Hi,

By the way, I really need you to add that second save point/healing shrine/whatever before the cave. I will not continue any of my balancing work until you do. I spent another half hour playing yesterday, got all the way to the cave, then Kayla died and I wasn't able to survive as I tried to run all the way back to the save point at the beginning. I can't work on balancing this game if I keep losing so much time testing because there are not enough areas to save my progress.

My two cents: instead you can edit your save game to start at the beginning of a specific map. It should help testing even at later stages and even when there a more save points by preventing you from going through certain maps again and again, or when waiting for a specific fix I was doing tonight, btw, when I saw your message: https://github.com/Bertram25/ValyriaTear/commit/8964a2be71d442a98ef9fa2c7399e17ff0a41d3f

On another note, maybe there could be an event triggered near the cave entrance that allows you to travel back to the beginning of the forest quickly? (Ie, an event where a tree falls, opening up a new path). I know that's not simple to do because it's an event that would affect two maps, but it would be pretty darn nice. Especially since you can also go back to the shop and buy any extra potions you need before the cave.

It's a good idea, and I'll think about it.

Bertram25 commented 11 years ago

Here is a first proposal as for the characters' stats. I'll start with this if there is no counter argument: https://docs.google.com/file/d/0ByDrwL5Fc7chUmZSM1RXMlZpMG8/edit

rootslinux commented 11 years ago

I would recommend that you open that document to be publicly readable instead of privileged access only. I can't see it until you either make it public or accept my access request, although I really don't think there's any reason to not have it be public.

Well today I managed to play through to the current end of the game. Here are some more changes I'd like to propose.

1) The bat enemy is too resilient. It takes a lot of hits to bring it down and it's attacks can deal significant damage. I feel that some combination of the following is in order:

2) The slime mother boss spawns too many slimes. I feel this skill should have a reduced likelihood of being selected (ie 25% of the time it spawns a slime as opposed to 50%). And perhaps the number of slimes spawned at any given time should be capped out at a maximum of three or so.

3) I feel I may have reduced the wolf boss' HP by too much. I might increase it back another 50% or so. But then again, I fought him at level 6 so maybe he should have been relatively easy at that high of a level.

4) It's way too difficult/time consuming to make it all the way back to the town from the later maps. You can't dodge every enemy and it takes a very long time to backtrack through 5+ maps to get there so you can re-stock up on potions. I think we need to either add some sort of shortcut back to the town from the map that contains the cave entrance, or have a random merchant nearby the cave with potions for sale, or something else.


Now a couple questions I need to ask before I can move onto my next round of balancing:

Q1) What XP level do you expect the characters to be at for the wolf boss fight?

Q2) What XP level do you expect the characters to be at for the slime boss fight?

By "expected level" I mean the level that players are most frequently at when they run into these encounters. The strength of these boss fights should be balanced around those levels so that they are neither too easy nor too difficult at that level. Obviously they will get harder or easier the further away from that "expected level" the characters are.

Bertram25 commented 11 years ago

Hi @rootslinux

I would recommend that you open that document to be publicly readable instead of privileged access only. I can't see it until you either make it public or accept my access request, although I really don't think there's any reason to not have it be public.

This now public, and should be available.

1) the bats

Go ahead with the bats. Sounds good to me.

2) The slime mother boss spawns too many slimes. I feel this skill should have a reduced likelihood of being selected (ie 25% of the time it spawns a slime as opposed to 50%). And perhaps the number of slimes spawned at any given time should be capped out at a maximum of three or so.

I'd like this monster to be a bad surprise for the player. Meaning that I'd like them to stress just a bit by a seeming overwhelming wave of enemies. Thus, I wonder if by just reducing the monster's agility, the battle could become a fair challenge for the player at level 6-7. Capping this is an additional stuff to program that I do find unnecessary if well balanced.

3) I feel I may have reduced the wolf boss' HP by too much. I might increase it back another 50% or so. But then again, I fought him at level 6 so maybe he should have been relatively easy at that high of a level.

Might be normal indeed.

4) It's way too difficult/time consuming to make it all the way back to the town from the later maps. You can't dodge every enemy and it takes a very long time to backtrack through 5+ maps to get there so you can re-stock up on potions. I think we need to either add some sort of shortcut back to the town from the map that contains the cave entrance, or have a random merchant nearby the cave with potions for sale, or something else.

Yep, as told before the shortcut is a very good idea. I will change hopefully soon the north west map so that the characters can go back to the village with a shortcut from above the cave entrance. That should fix the problem. I don't believe on the merchant walking alone in a forest. ;) But there a few scene to add on my own to "explain" why orlinn can pass the caves on little story events in the cave maps.

Q1) What XP level do you expect the characters to be at for the wolf boss fight?

In short, I'd say level 3-5. it being beatable at level 3 would rather good, since the wolf is met rather soon. The wolf will be met for a second time after the two caves and it should beatable at level 8. Then a few movements later and they'll meet him for the last time where it should be challenging at level 8 and feasible at level 9-10.

Q2) What XP level do you expect the characters to be at for the slime boss fight?

I'd say 6-7, as said in the previous point.

We might even want to let a note in enemies.lua about the expected level for each monsters, along with the monsters traits. It might help, right?

Thanks for your participation on this. And glad allacrost is online again. :)

rootslinux commented 11 years ago

This now public, and should be available.

Your spreadsheet data looks great. I'm going to work on integrating this data into the game. I do think we need to refine the XP to next level data some more though. I think it's pretty ridiculous that you require millions of XP to reach the next level once you reach level 46. But the first 20 levels or so look reasonable, so I'll populate the XP table up to there for now.

2) The slime mother boss

Makes sense. I'll reduce it's agility by a bit. When I fought it my characters were at level 7 and it was a fair challenge.

Q2) I'd say 6-7, as said in the previous point.

Alright. I do want to point out that if we assume a level cap of 100 and the time to grow an XP level is roughly the same, you're eating up a large chunk of the levels for just the first two dungeon maps (forest + cave). I'm not sure how long of a game you intend for VT to become, but I just want to make this fact clear.

We might even want to let a note in enemies.lua about the expected level for each monsters, along with the monsters traits.

Indeed. Especially for boss enemies, it would be very helpful to have a comment on what level we expect the player to face them at. I'm not sure if we need a recommend level comment for every regular enemy though.


Alright, here's what I plan to do now:

1) Make all the enemy stat changes that I proposed. 2) Submit a pull request for all the changes I've made thus far to my balancing branch (includes changes to enemy stats and a few skills) 3) Integrate the new character XP growth and levelling stats from the table you put together 4) Start the game over from the beginning and play through again, then propose another round of adjustments.

One final question to ponder. I'm wondering if we should change the format in which we store growth stats for characters. Currently, it looks something like this:

[code] growth_stats = { [1] = { hit_points = 5.0, skill_points = 1.0, strength = 2.0, vigor = 1.0, fortitude = 2.0, protection = 1.0, agility = 1.0, evade = 0.0 }, [6] = { hit_points = 5.0, skill_points = 2.0, strength = 3.0, vigor = 2.0, fortitude = 3.0, protection = 1.0, agility = 1.0, evade = 0.0 } }, [/code]

Each character has one of those tables. Anytime we want to change the value at which a certain stat grows, we have to make a new entry in the table for the level where that takes place. Unfortunately, this requires us to set -all- of the stats for that level, even if we only want to change one. In your current stats table, the agility cycles between 0 and 1 for each level, meaning that if we stuck with that, we'd have to write a table entry for each level.

I think that instead of that, I'd like to change it so that we tables for each stat like so:

[code] growth_hit_points = { 5, 5, 5, 5, 13, 13, 13, 13, 21, 21, -- Levels 1-10 21, 21, 29, 29, 29, ... }, growth_agility = { 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, -- Levels 1-10 0, 1, 0, 1, 0, ... }, [/code]

And so on for each stat. This would require some work on the code to handle the new model, but I think it would be best for us in the long run. Do you agree? If so, I'll include work on my list.

Bertram25 commented 11 years ago

Hi,

Your spreadsheet data looks great. I'm going to work on integrating this data into the game.

Cool, thanks. :)

I do think we need to refine the XP to next level data some more though. I think it's pretty ridiculous that you require millions of XP to reach the next level once you reach level 46. But the first 20 levels or so look reasonable, so I'll populate the XP table up to there for now.

I do think the same and that's why I lowered the ^1.025 to ^ 1.005 as you might have noticed. But indeed, this is not yet perfect. Why not diminish the factor each 20 levels and see how it turns?

Alright. I do want to point out that if we assume a level cap of 100 and the time to grow an XP level is roughly the same, you're eating up a large chunk of the levels for just the first two dungeon maps (forest + cave). I'm not sure how long of a game you intend for VT to become, but I just want to make this fact clear.

It's a fair warning, yet, I must say I'm taking example here to Breath of Fire II, and the serie in general where to beat the first dungeon you reach the tenth level, or even more, half more for the next one, and roughly five levels per dungeons after that. Btw, those games usually ends while you're reaching lvl 45 or so, and they put enemies nearly impossible to beat for the last dungeon and you have to grind for 25 lvl at least to finish the game.

So, what I'd like to keep here from those games is the fact that reaching level 10 early is making the player enthusiastic, at least I was ;) And we'll be less level givers after that I guess. Remember we're still in the introduction time of the game.

I'm not sure if we need a recommend level comment for every regular enemy though. Well, I guess it can't hurt. Might also be a level range, which is more accurate in fact, since you'll face the same enemies from level X to Y in a given dungeon.

1) Make all the enemy stat changes that I proposed. 2) Submit a pull request for all the changes I've made thus far to my balancing branch (includes changes to enemy stats and a few skills) 3) Integrate the new character XP growth and levelling stats from the table you put together 4) Start the game over from the beginning and play through again, then propose another round of adjustments.

Note that I imported your changes made so far to try them out (and with satisfaction :]). You might want to create a brand-new branch for that.

One final question to ponder. I'm wondering if we should change the format in which we store growth stats for characters.

Makes sense for data loading speed and writting compression, but less if we have to later edit them, or reduce/increase the level range. To ease that while keeping a compressed format, I'd propose, but it's up to you, to add a new line every ten values for instance along with documentation of how it works, so that we keep it readable. The overall idea is fine to me. :)

Best regards,

rootslinux commented 11 years ago

Update: I've added the new growth tables for both the next experience level and the character stats. Here's what it looks like (this table is for Bronann and covers levels 1-20).

    -- Begin character growth tables. Every line within these tables contains 10 elements to represent the stat growth for every 10 levels
    growth = {
        experience_to_next_level = {
            100, 112, 126, 142, 161, 183, 209, 238, 273, 315,
            363, 421, 490, 572, 670, 788, 931, 1105, 1316, 1575
        },

        hit_points = {
            5, 5, 5, 5, 13, 13, 13, 13, 21, 21,
            21, 21, 29, 29, 29, 29, 37, 37, 37, 37
        },

        skill_points = {
            1, 1, 1, 1, 1, 2, 2, 2, 2, 2,
            3, 3, 3, 3, 3, 4, 4, 4, 4, 4    
        },

        strength = {
            2, 2, 2, 2, 2, 2, 3, 3, 3, 3,
            3, 3, 4, 4, 4, 4, 4, 4, 5, 5
        },

        vigor = {
            1, 1, 1, 1, 1, 1, 1, 2, 2, 2,
            2, 2, 2, 2, 3, 3, 3, 3, 3, 3
        },

        fortitude = {
            2, 2, 2, 2, 2, 2, 3, 3, 3, 3,
            3, 3, 4, 4, 4, 4, 4, 4, 5, 5
        },

        protection = {
            1, 1, 1, 1, 1, 1, 1, 2, 2, 2,
            2, 2, 2, 2, 3, 3, 3, 3, 3, 3
        },

        agility = {
            1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 
            1, 0, 1, 0, 1, 0, 1, 0, 1, 0
        },

        evade = {
            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0,
            0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0
        }
    },

It took a long time to import the spreadsheet data and format it like this, which is why I only opted to do the first 20 levels for the four characters. I think the format is nice and it is easy to read. Adding the new table for listing the next experience levels is a bit more challenging, because I have to make several changes to the global code so that it processes this data correctly.

There is one related thing that I'm thinking about changing. Currently the character class has members to hold the current XP and the XP for the next level. The problem is that the later is not really the number of XP needed for the next level, but the total XP needed to achieve that level. In other words, the player reaches the next level when "new XP >= current XP + next XP". It's kind of confusing. I was thinking instead to make next XP simply a counter that counts down to zero. So then the next level would happen when "next XP - gained XP <= 0". Really, we don't need nor use the "current XP" member at all, nor do we report to the player how many experience points a character has (it's really worthless information). All of our XP reporting in battle mode and menu mode are all about the next XP member.

So doing this change would only slightly improve the code readability and make it easier to use next XP in the various game modes (because as they are now, they have to manually calculate the "actual" next XP). I'm debating whether I should do this or not. If I do, now is the best time because making this change after the release will introduce complications (due to the way that next XP is stored in save game files). What do you think, should I go ahead and make this change?

Bertram25 commented 11 years ago

Hi @rootslinux

Update: I've added the new growth tables for both the next experience level and the character stats. Here's what it looks like (this table is for Bronann and covers levels 1-20).

Looks fine so far. :) Plus, importing just the first twenty levels permits us to review the XP formula later.

It took a long time to import the spreadsheet data and format it like this, which is why I only opted to do the first 20 levels for the four characters.

I wondered: If you export the spreadsheet as CSV, open it with some text editor, and copy the comma separated values, would it be faster?

So doing this change would only slightly improve the code readability and make it easier to use next XP in the various game modes (because as they are now, they have to manually calculate the "actual" next XP). I'm debating whether I should do this or not. If I do, now is the best time because making this change after the release will introduce complications (due to the way that next XP is stored in save game files). What do you think, should I go ahead and make this change?

There is indeed something fishy here, as I had to fix the counting myself earlier, and found at the time that something needed to be done maybe. If it can simplify it and get rid of useless info, then I'm fine as long as gaining multiple level at a time is run-checked (When XP is counting and you're confirming, making all the xp given at once.)

Best regards,

rootslinux commented 11 years ago

I wondered: If you export the spreadsheet as CSV, open it with some text editor, and copy the comma separated values, would it be faster?

I thought about that, but I don't think it would be any easier because the data for each stat is organized in columns, not rows. It's not difficult to copy manually. Just tedious.

There is indeed something fishy here, as I had to fix the counting myself earlier, and found at the time that something needed to be done maybe. If it can simplify it and get rid of useless info, then I'm fine as long as gaining multiple level at a time is run-checked (When XP is counting and you're confirming, making all the xp given at once.)

Okay, I'll get to work on this right away then. It will likely require me to make changes to the battle code and menu code to work with the new next XP correctly. I'm going to leave the member that retains the total amount of XP earned, just in case either VT, or Allacrost, or some other game has a use for it in the future. I'll leave a note that it's there, but not really used as next XP is all that we care about.

Once I have that change in, I'm going to start a new game to play through and make sure that the leveling code works correctly. And after fixing any issues, I'll be sending a rather large pull request your way. :)

Bertram25 commented 11 years ago

I thought about that, but I don't think it would be any easier because the data for each stat is organized in columns, not rows. It's not difficult to copy manually. Just tedious.

Just copy/paste the data transposed into another sheet then. In LibreOffice: copy a range then Edit->Special paste (Check the transpose checkbox). Roughly the same goes for Excel. Might help.

Have fun!

rootslinux commented 11 years ago

I am considering removing the GlobalCharacterGrowth class (found in src/common/global/global_actors.*). When I originally wrote that class, I intended it handle all matters related to character growth to prevent the GlobalCharacter class from becoming too large. However, it's not working out the way I had envisioned, and a lot of code has to get access to this class object for each character to do anything related to character growth. If I removed this class, I'd move all of the members and methods directly to the GlobalCharacter class, and consolidate where I am able to.

In fact, I might just remove all of the complex growth code. A feature in Allacrost was to gradually award increase in stats instead of awarding everything when a level was gained. Bertram, if VT has no desire or need for this feature, I recommend we remove it entirely. It makes the code so much simpler if you don't have to account for this.

I still haven't made up my mind if I want to do these two things, so I'm looking for your opinion on:

1) Do you agree with removing the GlobalCharacterGrowth class and moving all of it's members and methods to the GlobalCharacter class?

2) Do you agree about removing all of the code present that enables the gradual growth feature, which has not been used in either VT or Allacrost thus far?

rootslinux commented 11 years ago

After working on this a bit more, I think I'll go ahead and leave the periodic growth code in (we can remove later if needed). It isn't as complicated as I thought it would be, now that I have improved the flow of the growth code a significant degree. I'm still strongly considering removing the GlobalCharacterGrowth class though. It really doesn't made the code better or easier to use (quite the opposite in fact) and I can't think of a way to redesign it so that it works well.

Bertram25 commented 11 years ago

1) Do you agree with removing the GlobalCharacterGrowth class and moving all of it's members and methods to the GlobalCharacter class?

Yes.

2) Do you agree about removing all of the code present that enables the gradual growth feature, which has not been used in either VT or Allacrost thus far?

After working on this a bit more, I think I'll go ahead and leave the periodic growth code in (we can remove later if needed). It isn't as complicated as I thought it would be, now that I have improved the flow of the growth code a significant degree. I'm still strongly considering removing the GlobalCharacterGrowth class though. It really doesn't made the code better or easier to use (quite the opposite in fact) and I can't think of a way to redesign it so that it works well.

I haven't seen where the "gradual" growth code is, or maybe you're talking about the code that is searching through a map and get the corresponding growth second member, right? In any case, I'm in favour of this: What is talking exclusively about an object should be dealt within that object, so yeah, let's remove it if you found out it isn't necessary, but you're right about the fact that you should make sure to make the new system work fine before doing some cleanup there.

Have fun, both during the race and during your coding hunt. ;)

rootslinux commented 11 years ago

Ok great, glad you agree with me about removing that class. I am at the perfect position now to begin that work, so I'll start on it tonight.

The way periodic growth works is this: 1) There are several map containers (one for each stat) which hold the amount of XP required to earn that growth, and the growth amount itself in each element 2) As the character gains XP, this periodic growth is added to the character as it is earned (not just when they gain a level) 3) When a character gains a level, the remaining growth for that level is all awarded to the character

The thing that was never implemented that is needed to enable periodic growth is a function that determines what growth to award to the character at various amounts of XP. As a rule of thumb, we were going to reward roughly half of the growth for a stat at the end of a level and the other half gradually as the character earns XP during that level.

Enabling this feature is actually pretty easy, it's just the algorithm is a little complicated to write (it has a placeholder comment in one function). I'm going to leave it in for now because it doesn't get in the way too much or make things terribly complicated. And I don't intend to implement this algorithm anytime soon either, unless it's a feature you want to see in the next release.

Bertram25 commented 11 years ago

No, as long as the characters gets the points needed when levelling up, there is no point in enabling it. Thanks in advance for the work on this.

rootslinux commented 11 years ago

Alright, I finished up all the changes required for the growth code in my balancing branch. It required a lot of work, but I'm pretty happy with the result and it should make it easier for us to process character growth now. This code is not yet tested, and I'll be beginning that this evening by starting a new game from scratch (to test both that character growth works as expected, and all the balancing changes I've made in the previous weeks). Once that is tested, I am going to be submitting a pull request, and it's going to be a rather large one so you may want to check out the changes in this branch in advance and bring up any issues you have with it sooner rather than later (as I would have to retest any major change, and testing this feature requires a lot of time to do).

Also note that this change makes modifications to the saved game file, so any previous saved games may not work correctly. I believe that they still will, although they will be missing some data (the list of skills learned from the last level gained). This data is unimportant however and shouldn't cause any problems even if it is missing.

Bertram25 commented 11 years ago

Good to hear, and I hope your holidays were fine!

Looking forward the pull request :)

rootslinux commented 11 years ago

Just sent it. Please take action on it as soon as you are able to. It also includes several of the balancing changes that we've agreed upon earlier in this thread.

After this is approved, I'm going to do one more playthrough for balance testing. I already have made a few changes that are not in this commit to the spider and slime enemies. Basically, at level 1 they were way too tough (one spider and one slime left my party from full HP to on the verge of death). I decreased their strength so that they didn't do as much damage, and I also boosted their XP because it took too long to gain a level. I'll discuss these changes in more detail once the pull request is accepted and I can begin my full playthrough.

rootslinux commented 11 years ago

Been playing the game and I'm currently on level 4, in the map just past the wolf boss encounter. Here's what I think needs to be changed (and some of these are already in my pull request).

Bertram25 commented 11 years ago

Hi @rootslinux,

Spider and slime enemies are too strong versus level 1 characters. Starting with a party at HP, the groups of 1 spider + 1 slime, or 3 slimes, can easily kill one of the characters off. You pretty much can't stray to the next map because you have to go to the healing spring after every single battle, until you can reach level 2 and afford some equipment upgrades anyway. I reduced the strength of these enemies so that they do not deal as much damage when they strike.

I completely agree on that point.

Wolf boss was impossibly hard at level 3, and this was with the best equipment available. I reduced it's strength and defense so that it didn't hit so hard and that the characters could deal a fair amount of damage to it. Although now it seemed perhaps a little too weak. With the best equipment and full HP, I was able to defeat the boss without having to use any potions. I think that we might want to buff the wolf boss' HP a little bit (say from 160HP to 220HP) so that the fight has to last a little longer, and you really need a potion or two to survive it.

Yeah, I'd say if you have to use a potion during that battle (at level 3-4), you're good to go.

The defensive stance skill that Kalya learns at level 4 is not very good because it doesn't last more than about 2-3 turns (and reduces in intensity by half as well). I think to make this skill really worth it, it needs to last about 3-4 times longer than it does currently. Otherwise the HP you save from the increased defence just doesn't make economical sense when you consider that you skipped a turn to attack.

True. I must say I didn't come to think of it. I guess the main problem of that one is to be lasting enough on weak levels and but not too much on higher levels. I'd say go ahead, but you might have to cap it to prevent pseudo-infinite defensive stance. What do you think of: Make it last 8 turns (I wonder what it does in seconds for Kalya's turns) by finding a good simple formula with her stats at level 4. (If it is weak at level 1, I don't care.) and cap it to be no more than 15-20 turns. After all, the defensive stance will later have his group-wise mother skill. And why not another one single-targeted with further effects. :)

I feel that potions are too expensive. They cost nearly the same amount as some of the upgraded armor, and it's very difficult to keep your inventory stocked full with potions when you are also trying to save up for better equipment. I'd reduce their cost to about half of what it is currently, if you agree.

@shirish also told me several times it would have to be fine-tuned. And I think you're both right. So yes, feel free to do it and change again if you see fit.

To my defence, I'm trying to open the road, and I must say I didn't want to spend too much attention on the fine-tuning while doing so. Having someone dedicated to that, especially the one who created that system is a really great thing. Thanks again :)

rootslinux commented 11 years ago

Great, sounds good. I'll be submitting another round of balance changes soon taking your feedback into account. I'm currently at level 5 and about to fight the slime boss. My next set of changes will include any changes I think are necessary for the snake, bat, and slime mother enemies, as well as what we have discussed here.

rootslinux commented 11 years ago

Here's my next set of upcoming changes based on my playthrough tonight:

I've now played through to level 7 and the game is sufficiently challenging. I ran out of potions and had to limp back to the save point in the first cave, so now I have to make my way back to town to buy more potions to keep on going. This wouldn't have been a problem if the potions were half their cost when I started my game, so I think this should be okay.

I'm wondering if we should change Kayla's defense skill to a healing support skill. I feel that the skill would be used much more often if it restored HP than just gave a temporary defense buff (that's hard to notice the effect of anyway). What do you think about changing her level 4 skill from defensive stance to one that does a minor amount of healing? Maybe it could heal the whole party about +50HP and cost quite a lot of SP. That way the potions are still useful (since you can't use the heal skill very often and it doesn't heal an individual as much).

rootslinux commented 11 years ago

Oh also, where does the map currently "stop"? I fought the second Fenrir boss (he might have been a tad too easy, but it was okay) and made it to the next cave through the forest, and I thought I reached the end of that one (ran past another slime mother enemy), but the map didn't transition. Is that the end of the game currently? I need to continually be informed of how far I can go in the game when that changes, so that I can continue doing the balancing work as new content becomes available.

Bertram25 commented 11 years ago

Ah, you've put an avatar, great.

I've now played through to level 7 and the game is sufficiently challenging. I ran out of potions and had to limp back to the save point in the first cave, so now I have to make my way back to town to buy more potions to keep on going. This wouldn't have been a problem if the potions were half their cost when I started my game, so I think this should be okay.

Great! :)

I'm wondering if we should change Kayla's defense skill to a healing support skill. I feel that the skill would be used much more often if it restored HP than just gave a temporary defense buff (that's hard to notice the effect of anyway). What do you think about changing her level 4 skill from defensive stance to one that does a minor amount of healing? Maybe it could heal the whole party about +50HP and cost quite a lot of SP. That way the potions are still useful (since you can't use the heal skill very often and it doesn't heal an individual as much).

To be completely honest, I'd rather have her learn the 'First Aid' skill around level 7 since it's exactly what the spell is for, without being too strong magic. Can you go toward this?

Oh also, where does the map currently "stop"? I fought the second Fenrir boss (he might have been a tad too easy, but it was okay) and made it to the next cave through the forest, and I thought I reached the end of that one (ran past another slime mother enemy), but the map didn't transition. Is that the end of the game currently? I need to continually be informed of how far I can go in the game when that changes, so that I can continue doing the balancing work as new content becomes available.

I think you should have been as the commit message tells it:

Finished the next cave.
You can go through it but not yet to the map after as it doesn't exist yet.

Anyway, the map after that one is the last one. The next map I'll put will have the last save point, the actual boss fight (where the wolf should be quite more challenging, counting on the fact that Kalya should know about the first aid spell), and where Kalya and Bronann will finally catch Orlinn and know why he went so far in the forest among other things.

The HEIR release will end at that moment.

rootslinux commented 11 years ago

Okay, sounds great. I'll increase the duration of the defense skill and add in the first aid skill at level 7. I'll have another pull request for you in a day or so.

rootslinux commented 11 years ago

Submitted a new pull request with some minor changes. I didn't mess around with the defense skill duration time in this commit though. My characters are on level 8 now and with the new First Aid skill available and being able to afford to buy a lot of potions, my party is feeling pretty strong now. I'm waiting for the new map to become available before going any further.

I thought the First Aid skill required too little SP for how great it was, so I doubled it's SP usage from 2 to 4. Similarly with Stun Strike, that ability isn't that great because the Stun only lasts a very short time (less than a full turn I think), and at 5SP it wasn't practical to use. So I bumped it down to 3SP usage, and I think I'll take a look at increasing the duration of the stun too if that's possible.

Bertram25 commented 11 years ago

Late answer but I was kinda afk or afi with i as in internet.

Thanks fo the further changes. As a first note, I'll say that I've juste pushed the very last battle from the first release, so in term of battles, I'm done. I'll finish the whole scene, etc in further commits.

Thanks for the changes, I pushed them as soon as I could review them. :)

Bertram25 commented 11 years ago

Is there anyhting left here to do for the next release?

Bertram25 commented 11 years ago

@rootslinux Last call here. Is there anything left?

Bertram25 commented 11 years ago

Since roots didn't add anything, I'll close that one as for now. Everything sounds fine to me considering the HEI release.