3 ms·

What is it with Large Video Game Producers like Sony or EA interfering in studio internal technical detail decisions? I distinctly remember EA pushing the Fros

• bmitc 5y ago
  In the case of Sony and Naughty Dog, it's my understanding that Naughty Dog serves two purposes. One is that they are a game studio that makes games but the other is that they're a technology development studio that exports common tech for other Sony game studios to make their games with. While I'm on the side of Lisp and C++ makes me itchy, I can understand why that would be a hard sell.
• alexdss 5y ago
  Naughty Dog had very good reasons to avoid alienation that would come by sticking to their custom languages (not necessarily Lisp). Only one person on the team really properly knew how the GOAL compiler worked and how it interacted with the rest of the Naughty Dog toolchain, and that person would have to leave the company at some point. Remember that, since they are under the Sony umbrella, they would have to share technology around with the other teams. They were aware this could turn into an issue, and mention it in some interviews and e-mails: https://www.neogaf.com/threads/why-did-naughty-dog-abandon-g-o-a-l-an-old-long-usenet-thread-gives-public-insight.139054/ https://www.neogaf.com/threads/why-did-naughty-dog-abandon-g...
• syntheweave 5y ago
  It's a "can't win" scenario in that the presumed advantage of a large org is that studios can share tech and therefore get an edge in deploying it across all titles - but they can't do it in a way that's really optimized to anyone's particular situation. Depending on the structure and communication flows the game teams can feel like code was "thrown over the fence" at them, or they feel chained into a method of asset production, builds and testing that is, for their purposes, extremely costly. Generalizing an engine has always been a very hard, two dimensional problem: 1. If you're pushing the platform, you need every part of the asset pipeline to be optimized for it, and probably lower level runtime optimizations too. 2. If you're doing something well within the constraints, your bottleneck is on implementing the specific types of assets that will make your game unique. As games get more featureful more and more micro-categories of assets show up - bits of UI text, custom behaviors, scene transitions, camera movements and so forth. 3. If you do 1, then 2 becomes more challenging because you made more optimizing assumptions, so the game production may fall off schedule due to lousy tooling making it hard to actually test anything in-game. If you focus on 2, you don't have as many reusable parts, and you're adding pressure to optimize near the end of the dev cycle, which can result in catastrophic bugs from changing assumptions in the asset-code mix, like "we tightened when we load in streaming assets. This broke a cutscene trigger because now it loads at the wrong time." And then you add in an external tech group and you have another layer of communication to deal with, so the design or art teams can't just grab a coder and say "hey, this workflow sucks, give me a little support on this." Whether it's in the org or third-party, it's the same problem: you really need engine coders on staff to handle some things. But the case can always be made: "if we have an internal engine group we can put all the smartest people in one place and have them develop the next-gen graphics." And once you have that group, it's politically necessary for the management to make its tech as widely deployed as possible, otherwise, why budget for them? The engine teams at large publishers who follow this kind of hard separation are known for having relatively cushy, high-profile gigs, while game teams are disposable bodies that churn out necessary but low-value features. Conflicts of interest and fiefdoms emerge from that. Some of them do enforce rotations and other protocols to lower the barriers.