1,247 karma · joined October 10, 2014
ECS is one of the better examples of something that sounds good on paper but in practice, and crucially in production, doesn’t provide the sort of benefits that outweigh the friction it imposes.
There seems to be a myopia online around things like ECS, data oriented programming generally, writing games in C (as opposed to that horrible high level monstrosity C++…), optimization, etc. Those are all fine things in and of themselves (though I’ve never understood the opposition to C++ as anything other than nostalgia), but they are often discussed without being ground in the considerations of building a game. If you want to build a tech demo, great! However, the needs of building a game with hundreds of people, most of whom aren’t engineers, and to a quality/production level that even “simple” things become complicated, demand other things take precedence. I lead a team that facilitates a creative project, not to satisfy my technical desire to have optimal cache or thread utilization in every piece of code. The right tool is the one that gets you closer to the creative goal, and for gameplay code most of the time it probably looks like what Epic or Unity are shipping with their entity frameworks.
True ECS systems - and not frameworks that just have things called “entities” which own things called “components” - are hard to work with, almost by definition (ie you have to be very explicit about data layout and dependencies). They add a lot of friction upfront to solving the important and hard problem(s) while purporting to solve something that isn’t actually an issue in most cases (guess what, your N is likely < 10, modern cpus go brrr, etc). If you are working in a domain where you already know something about the performance and input size characteristics - particle systems are the go to example - then maybe ECS makes sense as a framework. Otherwise, I’d advocate for simpler oop approaches with heavy composition.
There are also staffing implications. If you no longer have to create LODs for your environment art, do you reprioritize your environment art outsource budget? Likewise lighting, if we can hit higher quality with 1/3 of the personnel, where does the budget then go to? The earlier you can get a handle on the implications of these new workflows, the better you'll be able to answer those questions.
In terms of general advice for junior engineers, I wouldn't get too caught up on technology (ie engine). The sorts of things I am looking for are: do you have strong computer science fundamentals? have you taken game related projects from conception to completion? how well do you work within inter-disciplinary teams? and do you evaluate your work from a user's (ie player's) perspective?
Unreal dominates AAA for third party studios and I don't think that will change in the near future. Whether Unreal expands its dominance to mobile is an open question, but with more HD games going to mobile (or starting development with HD and mobile as platforms) I would probably bet on it. Unity probably isn't going anywhere in the near future but I don't expect it to shake Unreal's hold on large game production; they're simply too far behind.
I am fairly pessimistic on VR as a whole, but there will likely still be a small market there for the foreseeable future. With Sony recommitting to VR for PS5 and Oculus continuing to pump some (albeit much smaller) money into the space, I expect VR to remain a stable niche. AR is a lot harder to predict as Apple is the big unknown. There are a lot of companies ready to jump on that opportunity (ie Niantic) if someone can figure out the right hardware.
I don't know what to say about a studio not using source control in 2021. I see student projects regularly with full version control and CI.
There are corners of game development that are more "chill" than others. Studios doing work-for-hire for other projects can build sustainable businesses. People in the "serious" game and simulation space seem to have a pretty normal work experience. Likewise shared tech teams at the biggest publishers/developers are more insulated from business variability and shifting project deadlines.
In board games developer and designer are distinct roles. If you have a familiarity with modern, you may know the names of the designers of certain games, but the developers of those games are essential for turning the raw specification of the game into the box of tokens and cards you buy at Target. A lot of hobbyist games don’t get that development work and while they might have unique ideas, they are essentially prototype.
One way of reading the film is as an epistemological exploration of modern society and how one character evolves their belief systems in the face of both ordinary and extraordinary events. I love the movie far more than the book because it doesn't neatly resolve the "truth" of what Ellie experiences, and it leaves the audience, minus this scene, in the same place as the protagonist.
Source: Worked for, but not currently employed at, several EA studios over the last decade, including as a junior engineer paid overtime.
Having worked on multiple Frostbite and multiple Unreal games, both engines are capable of building a wide variety of games. The discrepancies in my experience aren’t technical but organizational. It is hard to compete with the scale of Epic’s developer support organization and the wider industry inertia around their technology.
It's a mess and I don't think the (domestic) airline industry will look the same a year from now.