Casey has had massive impact on the AAA space, no doubt. But I think most of that comes through RAD Tools which was a relatively very small team of incredibly smart, high impact people. Blow has made some contributions on AAA titles but I think most of his career has been spent on smaller indie titles.

I’m not trying to discredit them, I’m just saying that it’s not like they’re AAA veterans who have shipped many titles from start to end, in that particular space.

▲

sarchertech 10 hours ago | parent [-]

Jon worked on Oddworld: Munch's Oddysee, Deus Ex: Invisible War, and Thief: Deadly Shadows.

Before that he founded a 14 person game studio in the pre dotcom era. Back then that was a decent sized team.

Casey worked on Dungeon Siege.

They were also very involved in the AAA community. And after 3 AAA games the vast majority of high impact devs would have moved into leadership roles or started their own studios.

▲

bellgrove 9 hours ago | parent [-]

The point I was trying to communicate was that most of their career was spent operating in an environment different than what some of us operate in today. I wasn't going after the _calibre_ of games they worked on but rather the environment; team size, investor/business expectations, scale of production, etc. Having worked in games myself around this era, I've experienced first-hand how different working on a title like Oddworld or Dungeon Siege is compared to a Cyberpunk or Assassin's Creed.

▲

sarchertech 8 hours ago | parent [-]

> Having worked in games myself around this era, I've experienced first-hand how different working on a title like Oddworld or Dungeon Siege is compared to a Cyberpunk or Assassin's Creed.

Cyberpunk was released 20 years after Dungeon Siege, so I don’t know what you mean this era.

Also Thief Deadly shadows had close to the same size dev team as Assassin’s Creed and a similar budget.

If you’re trying to make the claim that he doesn’t have much experience in modern $500 million dollar games. Then sure because they didn’t make $500 million games 20 years ago when either one was working in AAA gams.

	▲	bellgrove 7 hours ago \| parent [-]
		I worked in games from 2006 to 2014 on titles that I imagine are similar in scale & production to Oddworld or Dungeon Siege to something more like an EA or Rockstar flagship title towards the end of my career in the industry. On the latter end of my career we had dedicated build/release teams, dedicated mocap technicians, networking/multiplayer teams, international/distributed teams, finer-grained tools teams, dedicated DLC teams, etc. We had interns, we had to prepare for more media appearances, etc. It was a completely different environment. Again, I'm not trying to disparage the games they worked on, my point was the environment in which they were created. I admittedly don't know firsthand what Thief or Dungeon Siege were like but you can see the difference on Mobygames; these both have ~250-300 credited in total versus Assassin's Creed (and "only" the 2007 version) which has ~900 — it only goes up from there. This is not a rock solid comparison but it's probably a decent proxy to describe the scale of production. You could maybe argue that a title like Assassin's Creed had a bloated team, but as an IC that's not really in my control. But in more concrete terms what I mean is that in the Dungeon Siege/Oddword environment, sure I could have maybe said to my team — I'm going to rewrite "x" because it's not efficient enough, and then go heads down for a while and try to solve this problem. I didn't have that same luxury at the other end of the spectrum. On a smaller team I could maybe say — hey, I think we should drop C++/OOP because of "reasons", and have a somewhat realistic chance of persuading the team. This was unlikely to be taken seriously at your EA/R* type company. Beyond the games industry I'm not going to be taken seriously suggesting to my big tech employer to rewrite everything in Rust instead of Java because OO is evil or it's non-performant or whatever. As far as polymorphism and clean code go, I sometimes find value in leveraging these if they make sense. I may anticipate some persistence-layer migration in the future or feel defensive about the next few intern project and want to try and have some sort of guardrails to limit their blast-radius. Virtual functions are non-performant, Jon or Casey may argue, and they'd be right in their respective domain — but it's not really applicable in mine; even if I were to theoretically drive _my_ service latency down to zero, my end-user would notice no difference as most of the latency is spent on downstream services. Etc, etc.