| >This has some advantages but it doesn’t scale and it makes it basically “dark knowledge” for LLMs or people without access to those that know it. We call this "tribal knowledge" in games. I despise it. It's done for a few reasons: - NDAs make public knowledge a landmine. And every game studio makes you sign NDAs. Even at the interview stage. - Churn. No one gets time to really develop expertise as they work on a project for 2-3 years and then layoffs come. Only a relative few become experts, and probably not because of the studio itself - lack of incentives. Games aren't very connected with acedemia to begin with, despite relying so much on cutting edge tech. So the best resources for sharing such techniques is shafted. This is slowly getting better as more tech conferences talk about games tech, but it's a pretty slow tricke unless you come from one of the largest studios and specifically come in for R&D. >If you want to get into an area like this, you often need to find a way to spend a lot of time with people that already know it. All too true. Open source development is one bastion for this, but that's overall why I keep trying to stay in this domain. You literally can't get the knowledge elsewhere. And it's knowledge that directly leads to better looking, more optimal, and less buggy games overall. |
There are some elegant and sophisticated techniques related to database kernels that have been passed around for a decade or two over beers that still don’t have a single reference in literature that I can find. The original researchers probably stayed quiet because it was under strict NDA but also likely retired years ago. No one writes it down because it sort of feels wrong to claim second-hand knowledge of unknown origin as your own, or to even lead people to assume as much. You show people, and they think it is amazing, but when they ask you for references or sources you have no idea where it came from.
There is a real gap here and it is getting worse.