|
|
Post by Dslyecix on Aug 9, 2018 18:15:26 GMT
Hey there, thanks again for all you've done for us with this set of tutorials!
I've been following everything up to the Stats lesson so far with few issues, all resolved slowly. I can't seem to work this one out though, hopefully something obvious I'm missing.
Regarding the numbers I'm getting in the Test scene, I see these results (such as these) in the console logs:
Name:Josh Level:3 Exp:416
Josh would have received 90 experience, but we multiplied by 2
Name:Josh Level:4 Exp:1012
Of course, it's kind of obvious that in this case we multiplied Josh's *total* EXP by two, after first adding the 90. This is not how I imagine it should go, and seems that the order of operations is wrong. I'm having an issue untangling exactly where/what to change, as I'm still somewhat new to events, handlers and arguments, and keeping a clear head about what we've done from previous lessons is a bit rough.
Is there some way to make the multiply modifier apply to the 90 experience (in this case), or are we stuck modifying the total? Am I correct that this is a 'bug' or is this intentional?
|
|
|
|
Post by Dslyecix on Aug 9, 2018 21:58:21 GMT
Sorry for just thinking out loud, I'm a bit over my head with the 'sudden' (my shortcoming) implementation of the Notification center, various 'event'-like concepts like Exceptions and so on in the tutorial series. I am poring through everything more in-depth and I'm sure slowly it is coming together for me.
I have yet to visualize how to get the "x2" effect to apply only to the awarded XP, and not the base value of the current stat as seems to be happening.
|
|
|
|
Post by Dslyecix on Aug 9, 2018 23:29:39 GMT
Ah nevermind! I think I get that this is just a mix up of a few things. The test script is just that, not intended to be a 'final implementation' of anything but to test the functionality of a few features. The GetModifiedValue() method of the ValueChangeException class does indeed just operate on the 'toValue' of the VCE, and so it doesn't operate the way I was picturing it should. Of course we have the 'delta' variable to use for figuring out how to use modifiers that way. This was mostly a matter of me not thouroughly understanding the flow of the system you set up. Got a bit ahead of myself  . |
|
|
|
Post by Admin on Aug 10, 2018 13:14:01 GMT
It sounds like you understand it all now, but just as a heads up for anyone else, you can see an example of using the multiplier based on the delta in part 17: Status Effects.
|
|
|
|
Post by xDGameStudios on Feb 7, 2019 0:40:05 GMT
Hi there I didn’t create a new thread because this one seemed almost related to what I wanted to ask!
I’m having trouble understand the differences between StatModifiers and the Features... couldn’t we use the StatModifiers to change the value of a player attack or defense?
For example I wanted a weapon that increase attack by 10% and an accessory that does the same 10% increase how could I make this?!
|
|
|
|
Post by Admin on Feb 7, 2019 16:36:18 GMT
The thread here was referring to the `ValueChangeException` script. These are changes that alter other changes before they are applied. For example, the OP created a scenario where a unit was receiving experience, but there was "something" that should double the experience earning rate on that unit. The exception could be triggered any time the unit is awarded experience, without caring why or how the unit got the experience.
The `StatModifierFeature` is different for a couple of reasons. You are right that you might see it on a weapon which could increase an attack stat. This would then be applied when the weapon was equipped, but it would also need to be able to track the amount of its change so that it could undo it when/if the weapon was unequipped.
So this demonstrates that the feature has a more `known` event for when it will apply, and that it must also be able to undo its changes. The `ValueChangeException` does not have this ability - it just fires and forgets its changes. On the other hand, the `ValueChangeException` has a sort of ability that the feature does not have - it can work with a sorted sequence of other exceptions to build a math formula of how final values are derived.
Does that help?
|
|
|
|
Post by xDGameStudios on Feb 7, 2019 18:27:37 GMT
The "problem" is that the 'StatModifierFeature' actually modifies the base stat value so it has to know how the value would be when it is removed (item unequipped)... what if every time you "ask"/get for a given stat... there was a ValueChangeException that was created and the weapons would just (register to that call) and append modifiers to it and the value retrieved by the stats would be computed dynamically this way the base stat is never altered directly (only when you want a permanent change)... I know this could have performance problems but stats are not queried on a per frame basis.. so that shouldn't be a problem. Well but I'm no expert here, I'm actually pretty noob! And if you made the system this way, it must be a better way to do it! |
|
|
|
Post by xdgamestudios on Feb 7, 2019 18:47:40 GMT
Just created an account here in the forums what do you think of this approach for using ValueModifierException... or do you think this would become messy and unmaintainable? |
|
|
|
Post by Admin on Feb 7, 2019 22:22:33 GMT
Haha, thanks for the vote of confidence. I'm happy enough with my code, but there is no reason to assume it couldn't be better! In this case, I think you already understand the trade-off. You could make it dynamically calculate the stat in a way that is similar to the ValueModifierException each time the stat was checked. Since stat checks aren't invoked that often, you probably wouldn't notice performance problems. But something in me just doesn't like how "wasteful" it would seem to be to have to re-determine the stat each and every time. Also, depending on how you did this, the notifications end up boxing the stat change information which could potentially create more garbage collection later. This was a bigger issue in older versions of Unity than it will be now, but it's hard to let go of old optimization habits some times.
As an added bonus to the way it is now, you can read stats of units in the inspector, whereas if you changed to the proposed version you would need to resort to a debugger, etc.
|
|
|
|
Post by player on Nov 3, 2019 17:04:07 GMT
Hello,
I'm planning to implement the solution xD is talking about.
Namely, say you have equipment that boosts STR, by adding a number. Then you get a status effect, WEAK, that halve your STR. I'd need a sort order for this, like VCE.
I'm curious how you would implement this, what would be your general idea? I'm thinking of saving a list of modifiers for each stats for each units, Then anytime the stat change, it checks through that list of mods.
Thanks
|
|
|
|
Post by Admin on Nov 4, 2019 14:18:19 GMT
The way I understand xD's goal, is that he wanted to rely on the existing patterns (notification-based) that are used in the tutorial. In this kind of system, you are not responsible for maintaining your own list of modifiers. Rather, when you want something that such a list should modify, you simply post the notification, which those objects are observing, and they append themselves to a sortable list dynamically at the time the notification is posted. You would need a pretty good understanding of the VCE so you could copy what it does.
So for example, say your unit has a a stats component, and the game needs to query the unit's STR stat. The stat could be a property rather than a field, and inside of the properties getter, the unit would read its own "raw" base value of the stat, post a notification from itself, using a notification name that matches the type of stat you wanted, and having some sort of object parameter that can hold the list of modifiers which will observe the notification. After having posted the notification, any observer will now be included in this list. The list can be sorted, and the numbers can be run through the list of modifiers, until a final STR result is obtained and returned from the property.
|
|
.
