It doesn't matter to the subject at hand, but there are plenty of immigrants in French speaking countries as well as French speakers in countries with a lot of non-ethnic-French people (for example I have an older relative who was born in Morocco and speak French as her first language).
Regardless, as their first job was in Italy I'd sooner assume they are Italian.
> What’s interesting about this particular bunch of smart people, is that they are also what actors call “grounded”. There is little bullshit going around. Tech is not made for tech’s sake. We don’t even have an engine, in a time where even if you really just have a game, one game, one codebase, you would call silly codenames each library and each little bit of tech, and maybe put some big splash screens before your main titles. Made with.. xyz.
This is actually a lesson that originates from the early days of Call of Duty at IW. From what I’m told, IW never named their engine, because any time you name something it becomes a bit more of a thing, and you start working for it. And they were a studio making games, the game is the thing. Nothing else.
This taps into a really interesting idea that I've been thinking about a lot. In high school, when I first started making games, this is exactly what I'd do. I would have Unity open on two monitors, and post to my snapchat story of how excited I was to be an indie developer.
I had a similar thought when I watched the making of documentary for The Last Jedi, everyone was so excited that they were making a Star Wars movie. But in 1977, I'm sure George Lucas was just thrilled to be able to make what he wanted to make.
I think this is what PG meant when he described playing house[1]. I think there's a lower local maximum for imitating what your heroes did or innovating for the sake of innovating than the global maximum of trying to make something really good. There's nothing wrong with getting excited about what you're created, but if you have any way to direct that excitement, direct it towards making something that people will love. (Not something that you'll love making).
I don't know. I've played games where the engine had no name, and games where the studio-made engine had a name, and games where they licensed an engine and made it work. And I don't think there has been any kind of a trend in what games I've enjoyed more, or even which ones had better rendering. This sounds like one of those things that doesn't really matter, but if you've gotten used to doing it one way, you think it's the right way.
Author here - you are most definitely right, there is little correlation between game tech and end results anyways. It's mostly internal stuff, there are millions of other variables. But that doesn't mean that as far as internal policies go, that "engine without name" one doesn't make a lot of sense
Reminds me of Battlefield's endless reference to its amazing Frostbite engine, which didn't change the fact that their last ~4 releases (BF3,4,1,5) all hit walls at launch, earning EA and Dice the reputation that their titles launch as Alphas and you don't get the real game for a year after despite paying a full sticker price. Great engine though...
Also I realize I left out Hardline. It was intentional (though I heard it was a solid game despite its lackluster popularity and quick demise).
There is a horrible morass of politics in this area, to do with short term goals vs long term investment.
As a game approaches its release date, the codebase accrues technical debt in the form of title-specific hacks and optimizations, but also features and fixes that may be useful for other titles sharing the codebase. The former makes the latter difficult to propagate.
The pressure of internal milestones throughout a game project precludes the team devoting much time to significantly improving any shared codebase during any given title's development, but it also cannot happen any other way since that would involve "people not working on a game".
In this situation, a decision to mostly or entirely eschew code sharing begins to appear quite reasonable.
Although I only worked indirectly with Angelo during my time at Activision (Sledgehammer games on Danny Chan's team) he was a big influence on my career at the time. He gave a talk at the Activision summit that originally got me interested in machine learning. His weekly Friday links helped me greatly level up in rendering knowledge, and I liked them so much I continued the practice for almost two years at Funomena while I was there. Definitely interested to see where he ends up. The end of his goodbye hints that he's starting a startup or going indie rather than joining another big game company or FANG. Looking forward to his talk at GDC.
I think my time ended shortly before Angelo’s began, but my experience with Central Tech (worked mostly with Steve L. and Guarav) was that they were very talented generalists. They were the team you dropped in to work on C++ game code, Lua UI code, Erlang server code, or Python scripts. They were a resource to work on anything you needed and you could give them a task knowing it would be done well.
The director of development at BeachHead studios originally applied for Central Tech.
How do independent R&D teams know if something is already solved or not? There are so many papers out there, how can they focus obtaining the new information but try their own solutions as well for a commercial purpose? Maybe its a n00b question and it only means I have 0 R&D xp, but things I am thinking about is always found in a paper with tons of references.
That is why I not decided to choose a similar position, because what I feel I'd do is asking permission from my boss to check "all the necessary information out there" to make sure I am aware of existing technology not to reinvent or miss things. Would take infinite time obviously. :D
Author here - we are specialists who know their field. More or less, of course you can't know all, we also collaborate with each other, but keeping up with published research is not that tough. Also, not that useful, it is useful, yes, but in practice even a problem that is "solved" in the literature means only that you have some ideas of where to start. Dropping things to the specifics of production always implies a lot more R&D, even if the solution in the literature is actually, realistic, stable, fast etc...
18 comments
[ 3.2 ms ] story [ 57.3 ms ] threadRegardless, as their first job was in Italy I'd sooner assume they are Italian.
This is actually a lesson that originates from the early days of Call of Duty at IW. From what I’m told, IW never named their engine, because any time you name something it becomes a bit more of a thing, and you start working for it. And they were a studio making games, the game is the thing. Nothing else.
This taps into a really interesting idea that I've been thinking about a lot. In high school, when I first started making games, this is exactly what I'd do. I would have Unity open on two monitors, and post to my snapchat story of how excited I was to be an indie developer.
I had a similar thought when I watched the making of documentary for The Last Jedi, everyone was so excited that they were making a Star Wars movie. But in 1977, I'm sure George Lucas was just thrilled to be able to make what he wanted to make.
I think this is what PG meant when he described playing house[1]. I think there's a lower local maximum for imitating what your heroes did or innovating for the sake of innovating than the global maximum of trying to make something really good. There's nothing wrong with getting excited about what you're created, but if you have any way to direct that excitement, direct it towards making something that people will love. (Not something that you'll love making).
[1] http://paulgraham.com/before.html
Also I realize I left out Hardline. It was intentional (though I heard it was a solid game despite its lackluster popularity and quick demise).
There is a horrible morass of politics in this area, to do with short term goals vs long term investment.
As a game approaches its release date, the codebase accrues technical debt in the form of title-specific hacks and optimizations, but also features and fixes that may be useful for other titles sharing the codebase. The former makes the latter difficult to propagate.
The pressure of internal milestones throughout a game project precludes the team devoting much time to significantly improving any shared codebase during any given title's development, but it also cannot happen any other way since that would involve "people not working on a game".
In this situation, a decision to mostly or entirely eschew code sharing begins to appear quite reasonable.
The director of development at BeachHead studios originally applied for Central Tech.
That is why I not decided to choose a similar position, because what I feel I'd do is asking permission from my boss to check "all the necessary information out there" to make sure I am aware of existing technology not to reinvent or miss things. Would take infinite time obviously. :D