Just wanted to start out saying that all the additional effort into the documentation is much appreciated, and the recent live stream was a great way to connect w/ developers/creators. Although this is critical in nature, I offer this feedback in good faith, and believe in the potential of the team. 
Player Statistics Tutorial: Questions & Feedback:
Summary: I have found the documentation for the Player Statistics tutorial to be convoluted and potentially misguided for a couple of reasons which I will go over in detail below.
Key Areas of Confusion: Justification of why code its being written in this manner doesnāt check out for me, even after multiple reviews.
Format: I have some general feedback in areas I feel more certain on, and questions in others. Ill be weaving between them and keeping things sequential:
Starting from the top, we a few key term and a very general explanation making an arguably fair assumption, but an assumption none the less:
I think some areas to be included up to this point would be:
-
There are other pages that cover ways to use persistent data (with links), and this is an expansions on base knowledge that you will benefit from starting with in order to understand the contents of this tutorial
-
Wrapping the data together in a class isnāt required to associate it in verse inherently. Since the constructor isnāt actually persistent and we have to use unique names with persistence that we reference (and whoās namespace is retained between sessions) whenever reconstructing (aka updating) the class.
-
An example of a real world scenario youād use this in. (BR Victories in FN, Goals in RL/Races in RR, etc. Thereās not a single thing more relatable in UEFN, than Fortnite. This carries across to code examples currently containing dogs and catsā¦ wherever thereās an opportunity to use direct Fortnite examples, take that route.
)
- What Iād suggest as an alternative:
- Iād begin with an example of a normal int value update, and lead into handling intrinsically tied values before jumping straight into a nested constructor. Iād also highlight it isnāt required, but can be an effective way to encapsulate the association in the persistent data itself.
- Immediately wrapping the class and nesting the constructor for partial updates, before writing a partial update and understanding why had me lose my bearing almost immediately.
Key Takeaway: A clear understanding surrounding the āwhyā would go a long way.
Argument:
You donāt necessarily have to change the way that the tutorials currently organized and presented, however without linking to the other documentation or providing more insight into the decision making process, it seems to lack essential context.
Reasoning:
It includes advanced concepts in tandem with a novel/unique data storage type that up until this point was rarely (if ever) used. This can create confusion as to what is being done out of necessity and whatās simply āone of manyā ways to approach things.
In the exercise, what is the purpose of creating the StatType module and the score_stats w/ Debug Strings?
I noticed these classes arenāt ever referenced in persistence data, nor is the module included in a session based weakmap:
An the only perceivable way to me that these classes are associated is only through the partial constructor function:
If a lesson isnāt directly optimizing or solving a problem, it lacks a practical application. This approach left me feeling unsure about how things worked, leading to a lot of extra time spent refining the information into a more straightforward process.
Introducing concepts purely for their own sake starts to clash with the higher levels of tutorials, as the way we approach coding, logic, and problem-solving becomes more complex and rooted in reason.
Iām uncertain about whether or not I have an inaccurate understanding of what happens when adding persistence to my map, and would like some clarification on the following:
Quote from code comments:
?: Are all enums final from that point on, even outside of permissible classes?
Others Iāve consulted werenāt aware of this as an issue, which has been a major source of confusion for me. Clarity here is requests, and unless new light is shined upon the justification for the Debug String to make it relevant here, I would consider removing it to simplify the already complex process.
Suggested Solutions:
Assumptions:
- StatType module isnāt part of the persistent data
- Enum is an acceptable data format as long as its only referenced outside of persistent classes
A more effective strategy may be to define stat_type as an enum within the same module, which would simplify the implementation and allow for more dynamic applications. Additionally, creating a single enum along with a āToStringā function could potentially be less memory-intensive, eliminating the need for an abstract parent class or any class implementation. Even though any memory savings might be negligible at this scale, itās still worth considering for overall efficiency.
-
For the purpose of comparison in partial updates you can use case instead of ifās, and for the multifunctional desire to have a string ToString adds the addition of auto resolving.
-
In the case that we really need to avoid enum, I would also address the potential of simply including a string within the wrapper itself. While this is likely not an adequate solution, and would result in a debug identifier exceeding the memory cost of the class it exists to identify, addressing that when presenting an alternative would be a healthy pairing.
Iām very open to the possibility that Iāve missed something fundamental here, and am merely suggesting these points in hopes of receiving clarification. I hope this provides insightful and useful feedback.
Cheers.
-Lion
