Unreal Engine 4.17 Released

A newer game that has pretty decent lighting is PlayerUnknown Battlegrounds. Check it out, you might see less of those aggressive reflections.

They don't. It can feel like they do because the same libraries, models and shaders are reused a lot between games, but there's a lot of variety if you look hard enough. Comparing the look of RiME to Crackdown 3 to EVE Valkyrie shows there can be a lot of difference.

Have a browser through Unreal Engine's trailer showcase - https://www.youtube.com/playlist?list=PLZlv_N0_O1gYaMTM__mGE...

I think the possible explanation on why they may look different to you than other PBR engines (say renderman or unity) is that IIRC UE4 has slighly different curves for roughness and other properties. but still I would credit it to what the other comment said about shared assets and people using defaults.

you can see information from disney here: https://disney-animation.s3.amazonaws.com/library/s2012_pbs_...

and here are the ue4 docs, with some other references at the bottom: https://docs.unrealengine.com/latest/INT/Engine/Rendering/Ma...

But then there's the Borderlands games. Those are based on Unreal, but they don't look like any other game out there.

If they aren't straying far from the defaults then it should be obvious why they would look the same.

While an experienced Unreal developer knows what to look for, the average gamer most likely couldn't tell if a AAA game was using Unreal Engine 4.

Still amazing tech, just something I've noticed.

[0] https://www.youtube.com/watch?v=_nLGoqqDc0w

My thought it is because they use the default shaders (and/or the artists do glossy too much). That said..

Most, if not all, modern big engines use "deferred shading" and support normal/bump maps, gloss/reflection maps in addition to "normal" textures (lately every rendering engine that focuses on being realistic is switching to "Physically based rendering", that is very similar to "normal" rendering except that it obeys the "amount of (light) energy out can not be greater then the amount of energy in"(this also means linear light space, instead of logarithmic like we humans perceive)).

All the big rendering engines can, with the same equations in shaders, produce exactly the same result. The same results in regards to the direct "shading".

The other part of how a thing looks is lighting (aka "global illumination"), where the actual engine code is a lot more involved. Since you can't make, like raytracing does, light bounce off of things, you have to cheat (it uses too much processing power). Rendering engines cheat by, for example, plunking "light probes" around (unity had a good post about them, i can't find it now). The slight differences in lighting may not seem like much in a side by side comparison, but our brains use those little lighting clues meaning they(we) are sensitive to them.

There is also how many lights a rendering engine supports (and the distance they can cast light), how it does particles and can they emit light, how it does volumetric.. things (like smoke, maybe water and such), how good it is at reflections (are they precise, do they include dynamic things; note that they probably don't bounce twice), subsurface scattering (notable on skin), and probably more that i forgot.

Note that i simplified plenty. For example lighting and shading are closely related.

PS Reality is not like basic theory. Physically based rendering does give real world results but in reality everything has dust on it, or an oxide layer (aluminium especially), or a sulfide layer (copper likes sulphor). The other imperfection is the minor imperfections in smoothness, what the collective "they" do take into equation (see https://www.cs.cornell.edu/~srm/publications/EGSR07-btdf.pdf).

PPS "Physically based rendering".. as if Phong shading is based on something else. (PBR is still no where near reality, for reasons above)

The same with ID Tech, Unity, RAGE and CryTech/Dunia games. One can spot them "from 50 feets away", or at least when trying out the controls, the character physic gets rarely changed at all. (I cannot say the same thing for Frostbite 3 and AnvilNext, the are more modern.) And many Unreal and Unity games use the standard shaders included with the dev kit.

(e.g. Titanfall 2 based on Source 2 still feels very like the controls from Quake 1, well it's based on the same engine after all).

Epic definitely has one of the most productive and effective teams in software development. I just marvel at it every time.

How did Unreal manage to evolve so quickly? If it was just one patch notes then may be just a coincidence, but they have manage to do it every time for the past months or years. I cant think of a single software / middleware that has this pace of development. And Games Development were suppose to be hard?

Unreal is a "AAA" engine originally meant for large teams. It has much better level design tools and collaboration features, but all programming must be done in C++ which is fragile and can break the whole engine. Lighter scripting can be done with Blueprints which is good for designers making levels interactive. Unreal is a good choice if you are aiming to make a serious production with a team making large detailed levels.

The Unity Asset Store has many more plugins and it's easier to put together a sandbox type game with lots of features, since its managed code design makes it easier to drop in scripts other people have made. There are level design tool plugins available that mimic what Unreal does, but they aren't as polished and collaboration is harder.

It shows in the fact that Unity uses C# instead of C++, which has less historical baggage and is a bit safer, especially for junior devs I think.

Unreal seems to be for projects that need the raw power of C++, but don't want to go into doing their own thing.

I for one never met a Unreal dev, only a mass of Unity devs and the ones that do their own engine.

There are more tutorials out there for Unity but a lot of them are written by people who don't have much more of an idea of what they doing then you do.

Less experienced developers might benefit from using neither of these things at first, start with maybe basic 2d stuff using just SDL2, or maybe a framework like monogame.

This way you can learn a bit about game programming, fundamentally, without having to learn how to use the engines and its editors and so on.

I guess there is also the issue of licensing costs which are substantial, but that requires actually shipping for that to matter :)

Not only are there really, really good official video tutorials to get you up-and-running, but also while UE4 is definitely a complex piece of software, you can get started pretty easily just by knowing a few things. I think that having Blueprints is a huge win, since they allow you to very easily program without having to learn new language syntax, are easy to read, and the visual debugging/real-time flow chart capabilities are very cool.

After only a month or so (of inconsistent, hour-or-two-in-evenings hobby time), I feel pretty comfortable with the engine and need a lot less handholding than I expected to need at this point.

The sources of differences are:

Unity's primary audience has been hobbyists. Unreal's has been AAA devs. Unity doesn't ship games themselves, so they tend to focus on flashy, marketing-friendly features. Epic used to ship FPSs at least (they've slowed down in that area). Unity's huge audience pushes them into a large commitment to a ton of legacy architecture dating back to the web plugin. UE is on Ver4 (whereas Ver1 & 2 might predate Unity).

A big one is that Unity uses C# vs UE's C++. Garbage collection is great in the beginning. But, when you go to ship it becomes the enemy. You end up needing to structure everything to have no allocations at run time to avoid GC hitches. So, you start out coding like a modern app dev and end up coding like a classic embedded C dev. Except you aren't using C. You are using a language that tries to sneak allocations past you all over the place.

If you are a hobbyist, Unity is really great. It's great for experimenting, prototyping, and for remaking your own take on that game from 10+ years ago. If you want to make a modern game, be prepared to fight and rewrite a lot of the core of Unity. The editor is great though!

Unreal, however, is a lot more complex and challenging to get started. And, it's not all roses when it comes to shipping either. UE tends to favor a heavyweight setup cost in order to make using high-end features a bit cheaper. That's not great if you don't actually want to pay for those features. UE is technically on mobile, but only because high-end mobile hardware is catching up to what UE requires. Getting UE to run 60fps has been a challenge forever. The Mortal Kombat team has at least one GDC talk about the extensive surgery they had to perform because their management dictated that they use UE.

Following that guide i managed to get it running on debian and gentoo systems. I'm not a pro developer, so i might have not touched all features to test them, but to me it seemed to work fine. Didnt do any programming for it on linux yet, so dont know how to or if its possible to build the code on linux, but the engine itself works fine. blueprints etc. and standard features worked fine too.

Not a book, but this course has been the best resource I've found. Just wait for one of Udemy's constant discounts so you don't have to pay more than $10-15 for it.