[zubspace]

I don't know if this is a blessing or a curse. 3D games are very complex. It takes years to grok all the concepts from linear algebra, to scene management, occlusion culling, shaders, physically based rendering, network synchronization, scripting and ai, game design and thousand other things.

I think a large part, why smaller, "indy" engines like haxeflixel, godot, cocos-2d etc are surviving is because of the much lower entry level. I wonder if the big ones like unreal, unity and crysis are going to collapse sometime under their own weight... How are they even adding all those new features without breaking stuff all the time? This is what impresses me most.

[daenz]

> I wonder if the big ones like unreal, unity and crysis are going to collapse sometime under their own weight...How are they even adding all those new features without breaking stuff all the time? This is what impresses me most.

I haven't looked at their code, but I would bet they have fantastic regression tests. Something I've added to my own engine in the past year is "pixel perfect" tests: for a given test scene employing specific effects (soft shadows, reflections, refraction, etc) the renderer should produce an image that is a pixel perfect match with a known correct image. If you begin optimizing shaders and rendering code, regressions are caught very quickly, in an automated way. Sometimes the images are close enough to be acceptable (for example, if an optimization changed floating point precision, resulting in a color that is a shade different). In that case, the test fails, and you can replace the test image with your new rendered image, after you've vetted that it "looks correct" manually.

It's not anywhere close perfect in testing all code paths, but the payoff is rather large for the effort put into creating the test.

[zubspace]

Things get interesting when the number of possible code paths increase. One such beast is the Unity Standard Shader. There are dozens of combinations depening on Metallic/Specular PBR, Multi-Texturing, Shadows, Light Types, Light Baking, Forward/Deferred Rendering and so on. Combine this with different backends (OpenGL, OpenGL ES, DirectX, Vulcan) and graphic card abilities and at some point adding new stuff gets quite complex.

I guess they simply throw money and play testers at this problem. (Unreal probably more so than Unity) But how long can you scale this up?

[mahyarm]

In iOS they're called snapshot tests.

[brandonwamboldt]

The UE4 codebase is very well built and organized for the most part (some legacy code is a mess). Even the community has managed to add quite a few large features to the engine, so I don't worry about it being unmaintainable. I often look through the code base to see how they do things and never have trouble finding my way around.

[ronjouch]

> I think a large part, why smaller, "indie" engines like haxeflixel, godot, cocos-2d etc are surviving is because of the much lower entry level. I wonder if the big ones like unreal, unity and crysis are going to collapse sometime under their own weight... How are they even adding all those new features without breaking stuff all the time?

Apart from technical answers for good engineering practice, I'd just say they do it with money (engineering time). And as long as gamers keep drooling at next-gen graphics, they'll merrily keep maintaining this beast they've assembled :)

UE vs. the indie engines you mention are very different economical animals. Where these indie engines are made by volunteers or small/medium teams, UE is built by the huge team at Epic, they've been doing it for years, it will cost you (a "5% royalty based on gross revenue" [1]).

So, not diminishing their technical prowesses at all, just reminding they pursue a juicy market which wants these weighty features so that their new AAA games stay on top of whatever new hardware and graphics advancements without having to research/implement those themselves.

[1] https://www.unrealengine.com/custom-licensing

[TrevorJ]

There's still a lot of abstraction in play though: you don't need to know everything about the low level implementation to use the engine. Even so, it took me about 6 months of working in the engine 30-40 hours a week to really become proficient and I've done 3D/2D graphics work for 15 + years.

[zubspace]

That's an interesting point. Think of someone getting into this stuff early in his career. How long will it take to get proficient? In my opinion, it's necessary to know the underlying principles to use the abstractions well. So 10 to 15 years sounds about reasonable.

In your case, the landscape was quite different 15 years ago. Simpler, in a lot of ways. Now think 15 years into the future and imagine how the Unreal Engine could look like then. If the changelist increases in this form for the next 15 years, how complex will it be to operate that thing? Will someone new to this still be able to learn everything there is to learn? If not, how will this affect the industry?

[darkmighty]

I disagree about needing to know the underlying principles. All you need is a sufficiently good functional understanding for the task at hand. You don't need to know about lie groups and linear algebra to rotate an object with your hand. If the engine gives you the tools, you can just use them (again, if you have a sufficiently good functional model in your head). Of course, maintaining the critical parts of the engine is another thing entirely, but even then they're divided so that each person only needs to understand a region of the code.

[ousta]

this is why very very few people will know all parts of the engine and dev teams would rather assign specific parts of an engine to different devs/specialists. this even make sense for a company to do that. i can't imagine what would happen if the few guys who know all were to leave the company with all the knowledge.

[TrevorJ]

I think understanding how things are implemented intimately is something that certainly helps, but isn't 100% necessary in many cases until you want to start optimizing, or you are trying to do things the engine isn't designed to handle natively.

[andresmanz]

I think it's a blessing. For me the most wonderful thing about game development is learning. I could learn so many things already and thanks to large engines like UE, I can learn even more every day. The larger engines are often used at huge companies, where they can make use of pretty much every single feature sooner or later.

I love writing everything from scratch just for the sake of learning. And yet I love engines like UE for trying new stuff and real world projects.

In large code bases, automatic testing significantly facilitates adding new features. I don't really know how they test UE, though.