User experience #28
User experience #28
Conversation
…lating the level based on experience. Still need to calculate and update the experience required for the next level.
…tes the experience required to level up.
| let mut new_level = level; | ||
| let mut count: usize = 0; | ||
|
|
||
| loop { |
There was a problem hiding this comment.
Could you try instead an eager algorithm?
I'm thinking, as the experience of the user is a result of positive interactions, why not on each of those interactions, once registered as positive, why not eventually calculating the experience in this very moment?
There was a problem hiding this comment.
I'm not completely sure what you mean. I considered hard-coding the levels to prevent the running of this computation, but I obviously opted not to do that in the end. Is that what you're suggesting? We just hard-code the levels instead of having the on-chain calculations?
There was a problem hiding this comment.
if you describe me what is this loop doing, perhaps I try to explain my idea. Thanks :)
There was a problem hiding this comment.
Sure! Let's assume you are a new user (level 0) and work on a large project where you earn 1500 experience all at once. Without a loop, you would be leveled up to level 1, even though level 1 only requires 100 xp. The loop allows a calculation of multiple levels at once. So it will iterate through until it knows you can't level up again.
That's where the count variable comes in. There should NEVER be a time where someone levels up that many times at once. I wanted that to be a final security measure. If someone finds a way to cheat the system, it at least will not allow an infinite loop to run.
There was a problem hiding this comment.
this proposal from you is really interesting. It is suggesting new challenges:
when you say "Let's assume you are a new user (level 0) and work on a large project where you earn 1500 experience all at once."
this is considering user X worked on a big project. Big project means for example worked on task1, task2, task3....taskN right?
why not increasing the XP on each task?
we could think on other kind of limits: maximum one level increase per time? maximum one positive interaction every x hours. etc. I need to talk to some friends in the gaming industry, I remember some discussions about balancing that could come useful in this moment.
There was a problem hiding this comment.
Think at a kid, he makes an exam at the 1st class. He takes an amazing vote, should he go immediately to the third class? I'd limit by protocol the possibility to level up by more than a level at a time.
There was a problem hiding this comment.
Think at a kid, he makes an exam at the 1st class. He takes an amazing vote, should he go immediately to the third class? I'd limit by protocol the possibility to level up by more than a level at a time.
I don't think this is something that will really happen. I see my logic as a backup, security measure. Personally, I'm not really in favor of restricting the levels that can be gained on a specific task. It seems like it would be messy.
Each level requires an exponential amount of experience, so this shouldn't be a problem. I'm curious what everyone else thinks.
There was a problem hiding this comment.
I see a loop that repeat 10 times maximum right? And on each loop it is calling a method calc_exp_of_level. So theoretically for one task a person may level up up to 10 levels for one single task.
This is what initially looked messy to me. And for this reason I'm trying to suggest something a bit more linear.
Now, when you say "each level requires an exponential amount of experience, so this shouldn't be a problem". What is limiting a single task from giving an exponential amount of experience to one person?
There was a problem hiding this comment.
I haven't built anything to implement restrictions on experience per task. That's another issue we can take a look at. Let's set up a time to talk through this via chat. I think there's a disconnect here, maybe on my end. I want to make sure I'm following completely. What do you say? @virgiliolino @DeluxeRaph
| @@ -43,3 +44,74 @@ fn create_user_experiences() { | |||
| assert!(Popi::get_user_experience(account_id, ExperienceType::Frontend).is_err()); | |||
| }); | |||
| } | |||
| #[test] | |||
| fn update_user_experiences() { | |||
| new_test_ext().execute_with(|| { | |||
There was a problem hiding this comment.
those tests are perfect happy paths
In order to track how experienced a user is in any category, we needed a system to track this.
Due to the proven success of "gamifying" platforms, I decided to implement a leveling system. Instead of reading a large number that resembles how experienced a person is, there is now a level. The formula that's used to calculate this is documented in the code. I tried to make this relatively efficient, while keeping in mind potential updates in the future.
I have created a couple of tests to verify the functionality of this. Please let me know your thoughts!