The Problem: The state of the platform is unstable, the documentation is inaccurate, and a year+ in we don't have stable or clearly defined methods on how to properly utilize core game development dependencies such as player initialization.
It’s clear that UEFN is in a fledgling state, a period of rapid growth, and by that nature very difficult to manage and keep documentation updated let alone the platform stable. I am not here to complain about these issues or look for justification for them, they simply are the way things are. This post is going to be focused on creative solutions to these problems, because they are not going to magically go away, and if they were going to be fixed without intervention then it would have already happened.
This builds on a post I made earlier in the year:
What I would like to see in the future is a program that allows contributing developers who have been in the ecosystem for a long time to be able to submit updates to documentation and tutorials, and generally contribute to upkeeping accurate information on the UEFN documentation.
There are two primary ways that this can be impactful:
Example 1: Suggesting Improvement to Existing Articles
The Persistent Player Statistics tutorial doesn’t ever show the need to check Player.IsActive[] which is a glaring issue. This is a requirement of accessing, writing, and storing player data and needs to be included. Improvements like this can be suggested by the community, we can even write the updates, and then either diffs can be approved or it can be rewritten by staff after review, however you wanna slice it.
Example 2: Suggesting Missing Articles
Player Initialization: This is one of many errors related to the poor handling, understanding, and communication on how to manage player spawns and inits. You can see why there would be confusion by looking at example 1. Topics such as how to handle rudimentary functionality like players spawning is something you guys should really be able to do (this is probably the biggest offense of any on the platform) but if you cannot we can do that but we need to be empowered to.
To verify that a player is ready for initialization, you need to either run a loop that passes Player.IsActive or await FortCharacter.SprintedEvent. This crucial information isn’t in any documentation or examples, and I’ve learned it through thousands of hours of development and problem-solving. I understand that staff can’t be expected to have this level of experience, but it’s essential to empower the community. I’ve been clear in my feedback over the past six months: we need creative solutions. If we don’t, we’ll all end up worse off. The alternative is wasting time running in circles instead of building games.
How To Ensure This Will be Effective
Not everyone will have the correct answers. Some people seek high scores on forums by copying others’ solutions without context, while others may disagree on code implementation or struggle with communication and formatting. To address this, design and implement a vetting system for contributors, maintaining a status that must be upheld. This could involve concise suggestions integrated into existing documentation. Yes, it will require resources, but piloting such a program is a worthwhile investment. It prevents developers from being bogged down with rudimentary bug fixes and gating basic gameplay behind a complex knowledge base. We’re talking about tasks like initializing players, starting new rounds, and understanding platform quirks—things that can preventable errors and bugs with proper communication.
In Closing:
I’ve got over 3000 hours in UEFN, I think I can speak on this topic with as much authority as a UEFN developer can at this point:
The state of the documentation on the platform, and the effort to improve it is inadequate. Not doing things because they’re difficult is not an appropriate response to this (not improving things responds through action or lack thereof). If we’re going to have a ‘move fast’ haphazard development environment, I’d rather the documentation follow suit, instead of having documentation that hasn’t been updated since before the platform was launched. I have provided plenty of actionable examples on how these improvements can be made and I will contribute to them if implemented. I’d rather contribute to scalable solutions than answer 1 offs on the bugfix forum but I can only do what you let me do.
Thanks,
Lion
PS: Does this seem like we’re just doing QA for free? Yes. I just don’t see any other alternative. There is always the excuse that this is too much stuff to be able to support so I’m done dancing around it, let’s solve it.
