My favorite story about docs is when I tried implementing multithreaded Raycast in Unity.
I needed it to hit multiple targets per ray. Should be pretty easy, after all - there is this parameter right in the constructor:
maxHits: The maximum number of Colliders the ray can hit.
And this is how you use it, straight from the docs:
The result for a command at index N in the command buffer will be stored at index N * maxHits in the results buffer.
If maxHits is larger than the actual number of results for the command the result buffer will contain some invalid results which did not hit anything. The first invalid result is identified by the collider being null. The second and later invalid results are not written to by the raycast command so their colliders are not guaranteed to be null. When iterating over the results the loop should stop when the first invalid result is found.
Well, no. It’s not working like that. I was always getting just a single hit, but sometimes, I received two or more hits. After a few days of debugging, I have found a typo in bubblesort, which caused the multiple hits, and I was in fact getting only one hit every time.
Strange, must be a bug then. And then I found it. A bug report from 3 years ago. But it was closed as solved. And the resolution?
I have some news about the issue where RaycastCommand will only return a maximum of 1 hit regardless what you set maxHits to.
According to our developers, each individual raycast in a batch only does a Raycast single in PhysX which will only return the first hit, and not multiple hits if the ray passes through several objects which would require a different raycast function. The documentation simply doesn’t explain this very well.
The docs above are from 2021. Three years after this. The fuck “doesn’t simply explain it very well”? It literally explains it pretty damn well.
But looks like they’ve finally changed the docs for 2022+ at least, it did happen few years ago.
Ah, reminds me trying to implement multiplayer just as there was some churn regarding unet/llapi/hlapi and every update something would break.
I just gave up. Add it to the failed projects list.
We’ve once received an investor offer from a major studio for our game we are making since college in our free time, but the catch was that they wanted us to implement online multiplayer into a coop-only top-down shooter we’ve been actively making in our free time for the past 4 years at that point.
We ultimately rejected the offer, even though we managed to get a prototype working. MP is such a pain to implement in the first place, and adding it into an almost finished game is near impossible. But, if you ever resume the project you’ve scratched due to unet being awfull, I highly recommend checking out Mirror. It’s free, open-source and has an amazing Discord community - every time I had an issue or needed help with something, there was someone willing to help me there.
Because things keep changing and no one ever updates any docs or guides.
It would be nice to have a kind of central hub where all the lastest resources are listed.
I could be updated by the community.
Well… one can dream.
If it’s updated by the community, it’s probably also created by the community. Instead of dreaming, why not create it?
Stack Overflow tried that with their documentation project
If using docstrings/docblocks to generate SDK documentation, adding something like an OPA policy to validate their existence and semantic structure could help with coverage. Then we have the issue of accuracy, and that needs humans or AI to weigh in. I have a feeling test-driven development would make this process smoother.
You could also add git hooks to facilitate accountability / run the policies.
Yeah I built a few react apps that made it to production about 7 years ago.
Now the react syntax I used back then is basically a dead language.
This is why having a dedicated person/team to maintain docs is very important
I’ve always felt that programmers need one day out of the week where they explain what their code does to someone dedicated to writing documentation. That way the code is being documented while you still understand what it does and the documentation is constantly being updated.
I also feel like agile methodology, which is becoming more common, works against documentation with the fail fast fail often philosophy. If your feedback loop with your stakeholder is rapid, then changes to the design plan are often and rapid as well, which requires more documentation change overhead, which makes documentation even less appealing.
In fact SAFe Agile emphasizes working software over comprehensive documentation.
