Support NeoGAF

[Black_Stride]

You answered yourself:

But often times, new devs learn the tool rather than how to program properly. Many of them didn't even study programing and come from other areas like game design. Not to mention a lot of artists who know very little of the technical side of things and end up relying entirely on specific tools like fmod to integrate their work into the game, tools that oftentimes only work well with these standard engines.

Godot and unigine are basically dead end engines.
You aren't gonna see any AAA or even AA indie games running on either any time soon(if ever).

I tried learning Unigine.....a waste of my time, truly....and this is coming from someone who wasted literal years learning CryEngine 3.

A texture artist should not need to know the technical side of things same reason a game programmer could be a horrible designer or artist but they make things work.

Tech art need to make tools that make the artist lives as seemless as possible.

NDs lighting artists will use Maya for cutscenes then the project goes through the tech art program to integrate into the engine.
Anyone with a design or animation background could then in theory work for ND because Maya is industry standard.

It's better to have multiple masters than have few jack of all trades.

 

[PaintTinJr]

I'm not well versed in the technical details of all this as it's not my area of work, but Nanite and Nanite foliage (which are basically solving the same thing but foliage requires some special consideration) work first and foremost on polygon-dense meshes; which alpha cards aren't. There isn't much to do in terms of polygon reduction for alpha cards since they typically consist of only two polygons. The cost of overdraw remains the same as Nanite doesn't really have anything to do with the rendering cost of overdraw, but it makes using geometry instead of alpha cards all the more feasible.

With mesh based foliage you don't have overdraw since there is no transparency. Overdraw is expensive because you can't use visibility culling on transparent or translucent materials; you have to render what's behind an alpha card (or any transparent or translucent material). This is why it's expensive in foliage heavy environments using alpha cards; you have a ton of "has to render" elements. While the polygon count is low, each pixel is shaded multiple times.

Yeah that makes sense and what I thought you meant, but without me knowing specifically how nanite foliage generates or loads its data I couldn't be sure if there was a downside of nanite foliage, like maybe not being able to use Hierarchal-Z or being unable to pre-sort instances, resulting in some normal (random) back to front rendering - overdraw -or if you were talking about instances that overlapped each other in opposite depths guaranteeing some overdraw regardless of render/sort order.

But completely agree about the unavoidable transparency overdraw. It is a problem that with more layers the cost gets progressively worse and wore.

I suspect as ray tracing becomes a smaller percentage of total resource use, it will become the cheaper option for transparency because the contribution of lower layers become a fraction of a fraction, of a fraction - at which point RT rays would pre-emptively stop casting where as alpha cards would already be sorted and brute force blending together (overdrawn) back to front with no early exit.

 

[Guilty_AI]

A texture artist should not need to know the technical side of things same reason a game programmer could be a horrible designer or artist but they make things work.

Tech art need to make tools that make the artist lives as seemless as possible.

NDs lighting artists will use Maya for cutscenes then the project goes through the tech art program to integrate into the engine.
Anyone with a design or animation background could then in theory work for ND because Maya is industry standard.

It's better to have multiple masters than have few jack of all trades.

That mentality is precisely whats causing the current state of affairs. A bunch of masters who understand less and less of other segments of the work, then increasingly become more reliant on specific tools - commonly third party ones - in order for everything to be integrated properly as a game should. Then these specific tools eventually become a necessity, and all of their shortcomings become industry-wide issues.

Godot and unigine are basically dead end engines.
You aren't gonna see any AAA or even AA indie games running on either any time soon(if ever).

Godot is becoming more common these days among indies. We already have a bunch of hits made using it like Cruelty Squad, Buckshot roulette, Brotato, bloodthief and Parking Garage Rally Circuit.

 

[Black_Stride]

That mentality is precisely whats causing the current state of affairs. A bunch of masters who understand less and less of other segments of the work, then increasingly become more reliant on specific tools - commonly third party ones - in order for everything to be integrated properly as a game should. Then these specific tools eventually become a necessity, and all of their shortcomings become industry-wide issues.

Thats why you have project leads and collaborative design.

Ironically Unreal since Blueprint came really democratized game design but it lead to inefficient code, for a small project this isnt much of an issue, but with bigger projects or more complex ones finding why your game isnt running well becomes disastrous.

Have brilliant coders who translate what the designer wants into game code.....well chances are they will find the bug and fix it without breaking everything.
Game logic can be described to a programmer and they can implement it without needing to know what sounds the characters footsteps make.


An animator doesnt need to know what the underlying code is doing when some reloads a weapon, they need to know how to animate a good reload animation.


A modeler doesnt need to know how the engine tessellates or translates the model from the DCC, they just need to know how to work the DCC to get whatever the designers vision is, techart should be responsible for creating the right tool that can take that DCC asset and make it useable in the engine and or be able to explain to the modeler what they need to change to make the asset work.
Eventually the modeller will have an understanding of what the engine likes and doesnt like.
They couldnt know this without access to the engine or some sort of feedback.......now when you only have like 4 viable engines for someone to learn from what choices do they have.......I could never know what NDs engine likes for its models, but the internal techart team would know how most DCCs export assets and most likely already have tools for the vast majority of them.




Expecting everyone on the team to be good at everything is ridiculous and most likely what you actually end up with is a bunch of mediocre everythingers.

Godot is becoming more common these days among indies. We already have a bunch of hits made using it like Cruelty Squad, Buckshot roulette, Brotato, bloodthief and Parking Garage Rally Circuit.

And Godot is GDS(similar to Python) and C#(Unity).

So why exactly would learning Godot be beneficial to Game Designers over Unity, CryEngine or Unreal Engine?

 

[Guilty_AI]

Thats why you have project leads and collaborative design.

Ironically Unreal since Blueprint came really democratized game design but it lead to inefficient code, for a small project this isnt much of an issue, but with bigger projects or more complex ones finding why your game isnt running well becomes disastrous.

Have brilliant coders who translate what the designer wants into game code.....well chances are they will find the bug and fix it without breaking everything.

More people, more steps, more work, more time, more money, all to produce subpar solutions to one of the most fundamental aspects of game dev.

Game logic can be described to a programmer and they can implement it without needing to know what sounds the characters footsteps make.


An animator doesnt need to know what the underlying code is doing when some reloads a weapon, they need to know how to animate a good reload animation.


Expecting everyone on the team to be good at everything is ridiculous and most likely what you actually end up with is a bunch of mediocre everythingers.

That kind of hyper-modulation is how you end up with this, or worse. While this can make game dev feel more efficient, it ultimately leads to worse products even if individual, isolated parts look better.

You get a highly detailed, hyper realistic apple sculped by a super-talented artist. And when you shoot at it, it remains in place just as beautiful as before with a default bullet-hole decal.

And Godot is GDS(similar to Python) and C#(Unity).

So why exactly would learning Godot be beneficial to Game Designers over Unity, CryEngine or Unreal Engine?

It's free and open source for one. If you choose to learn Unity instead for example, you run the risk of getting burned by them one day deciding to change the business model out of nowhere, or taking weird decisions and actions that can completely ruin you and your project - things that happened already.

 

[Black_Stride]

It's free and open source for one. If you choose to learn Unity instead for example, you run the risk of getting burned by them one day deciding to change the business model out of nowhere, or taking weird decisions and actions that can completely ruin you and your project - things that happened already.

Godot only got PBR and GI in like version 3.0. (dont quote me)

What big projects do you seriously think are gonna be using Godot, and what dev studio do think would look at a resume with Godot and take it over a resume that has Unreal/Unity/CryEngine?

Godot has it uses, but in the AAA space?

Having the fundamentals of game design (whatever field) while using a more powerful engine will always look better than Godot or GameMaker or whatever other smallscale engine you want to bring to for.

Unigine literally useless unless you are going into the simulator space which isnt really what this conversation is about.







Your point was that "no talent goobers" only learn Unity/Unreal/Cry which is why studios use them.
But for someone learning game design for AA or AAA, realistically the only engines to learn are Unity/Unreal/Cry/Godot.........

So its a moot point to say they only learn (the only engines available to learn).

Not everyone is going to be an engine engineer and make their own engine and renderer in college.
So why not learn through proven engines.......if the studios uses a proprietary engine having that experience will make the onboarding process much easier.


If you are going to be a modeler, level designer, lighting artist or texture artist the engine you use for your portfolio is almost completely irrelevent as long as it has similar maps to other renderers and game engines..........I know alot of modelers and texture artists who exclusively use Marmoset Toolbag for their portfolio shots.....some of them are in the industry, and make no mistake they are talented.
When UE5 hit a big shift to it as their renderer happened even if the studios themselves dont use Unreal.
You can check proven game dev profiles and youll see that their portfolios will be filled with renders from the only available engines that people can use.

Im sure everyone would love to learn Decima or Anvil or Snowdrop or RAGE or NDs Engine.......but how exactly is someone supposed to learn those engines if they dont have access to them?

So the question i posed early still stands, what engine would game devs learn if the only engines available to learn arent good enough according to you?

 

[Guilty_AI]

Godot only got PBR and GI in like version 3.0. (dont quote me)

What big projects do you seriously think are gonna be using Godot, and what dev studio do think would look at a resume with Godot and take it over a resume that has Unreal/Unity/CryEngine?

Godot has it uses, but in the AAA space?

You said it was a dead engine, i pointed out it wasn't and was seeing plenty of use. I don't think it has much space in AAA either, much like Unity also doesn't.

Having the fundamentals of game design (whatever field) while using a more powerful engine will always look better than Godot or GameMaker or whatever other smallscale engine you want to bring to for.

Having the fundamentals of game design will let you pick the appropriate engine. If i want to make a visual novel, i'm not going to use Unreal nor should you.

Your point was that "no talent goobers" only learn Unity/Unreal/Cry which is why studios use them.
But for someone learning game design for AA or AAA, realistically the only engines to learn are Unity/Unreal/Cry/Godot.........

So its a moot point to say they only learn (the only engines available to learn).

They focus on learning it because it's what studios use, and studios use them because it's the only thing most of the available workers know how to use. It's a self-feeding vicious cycle.

In practice, you don't need to learn these engines to make games, you can very well make games using C++ or other basic coding language, even explore other available engines out there. Plenty of old game engines went open source and got modern ports, there are devs who work with those to make commercial products for example.

The point is you can learn game dev without hyper-focusing on how to use Unity&Unreal, and from that become a more flexible dev. But the "no talent goobers" would rather just learn those to put stuff on their resume more quickly, and from a purely job hunting perspective they aren't wrong.

Not everyone is going to be an engine engineer and make their own engine and renderer in college.
So why not learn through proven engines.......if the studios uses a proprietary engine having that experience will make the onboarding process much easier.

That doesn't mean you can't learn how they work or some fundamentals. In fact, they should.

If you are going to be a modeler, level designer, lighting artist or texture artist the engine you use for your portfolio is almost completely irrelevent as long as it has similar maps to other renderers and game engines..........I know alot of modelers and texture artists who exclusively use Marmoset Toolbag for their portfolio shots.....some of them are in the industry, and make no mistake they are talented.
When UE5 hit a big shift to it as their renderer happened even if the studios themselves dont use Unreal.
You can check proven game dev profiles and youll see that their portfolios will be filled with renders from the only available engines that people can use.

Im sure everyone would love to learn Decima or Anvil or Snowdrop or RAGE or NDs Engine.......but how exactly is someone supposed to learn those engines if they dont have access to them?

i won't say you are wrong. Like i said earlier, it's a self-feeding cycle where mediocre people enter the industry and push even more mediocrity into the new blood.

If they had more basic, general knowledge of how game engines work and programming and software engineering, it wouldn't be hard to teach them how to use in-house engines. But they don't, and instead of finding ways to fix these issues, the old blood would rather just adapt to the mediocre state of affairs and start using these tools, flawed and inadequate as they may be.

So the question i posed early still stands, what engine would game devs learn if the only engines available to learn arent good enough according to you?

They should stop focusing on engines and learn software engineering applied to games. Learning an engine should be a second, more mature step.

 

[Black_Stride]

You said it was a dead engine, i pointed out it wasn't and was seeing plenty of use. I don't think it has much space in AAA either, much like Unity also doesn't.

Genshin Impact is made in Unity.........I think Tarkov is also a Unity game........I couldnt even imagine trying to make either game using Godot or one of these other obscure engines you think young talent should be learning.

I said Godot was a dead end engine for AAA development (slight hyperbole)
If you are applying to a AAA or AA studio, Unreal/Unity/Cry will look better on your resume even if the studio doesnt actually use any of those engines.

They focus on learning it because it's what studios use, and studios use them because it's the only thing most of the available workers know how to use. It's a self-feeding vicious cycle.

They focus on learning these engines because these are the engines available.
If you come from GameMaker or whatever and apply to ND theyll likely laugh you out the studio because they would be effectively onboarding you for a near full year. (Assuming you arent there just as a coder in which case the engine is irrelevent cuz they would want you to be a good coder first and game designer second).
Having experience in something like CryEngine/Unreal/Unity they will know the onboarding isnt going to be that tough because you'd atleast have the knowledge of how alot of 3D game engines work.
Yes there will be differences, but you;d have the fundamentals.

Unreal Unity Cry are free to learn.
Its exactly the reason universities use them even if graduates might never use those engines in the work place.

In practice, you don't need to learn these engines to make games, you can very well make games using C++ or other basic coding language, even explore other available engines out there. Plenty of old game engines went open source and got modern ports, there are devs who work with those to make commercial products for example.

That is true.
But as I said not everyone wants to be an engine engineer and will make their own game engine.
Many studios use Lua, Python, C++ or C# why not learn game design using an already existing engine that uses those languages.
Why use some obscure engine that the studio may not even know is compatible with how they produce games?
At the end of the day most engines work in a similar fashion at this point, which is why you can see talent move from studio to studio and from engine to engine.
They fundamentally work the same (the 3D ones atleast).
The unique features of Engine X wouldnt have been created by the environment artist.....he could have requested the feature but it would almost certainly be an engineer who implements it.
Thats really my point.

That doesn't mean you can't learn how they work or some fundamentals. In fact, they should.

Are you assume the proprietary engines work in significantly different ways to Unreal/Unity/Cry?
The experience gained from those engines would be more valuable than experience from an obscure engine that may not even have a feature set thats usuable in todays AA dna AAA space.
Imagine using an engine that doesnt use Normals?
When they give you the tech test youll have no idea whats meant to be plugged in there, you might not even know its purpose?
With the 3D engines available you'd already have a decent idea even if you had never actually handled that specific engine.

If they had more basic, general knowledge of how game engines work and programming and software engineering, it wouldn't be hard to teach them how to use in-house engines. But they don't, and instead of finding ways to fix these issues, the old blood would rather just adapt to the mediocre state of affairs and start using these tools, flawed and inadequate as they may be.


They should stop focusing on engines and learn software engineering applied to games. Learning an engine should be a second, more mature step.

If im a modeler or texture artist or lighting artist why should I need to learn software engineering.......ill literally never alter the engine.
The engine engineers and techart will modify the engine according to my needs.
Thats why you have techart and engine engineers.
Even if all I do is program the game logic, I dont need to know engineering for that.

If we want to blame Unreal for something its that studios have stopped putting emphasis in techart and engine engineering and are effectively using stock UE.
So studios should be hunting for those engine engineers who can modify the engine to achieve the vision.......not that we should have the whole studio be filled with engine engineers, thats a 4 year degree.......let the guys who know that shit do that shit......let the guys who are artists or designers be artists or designers.
Its not actually Unreal Engines fault its the studios.
The Coalition modify Unreal Engine enough that some of their solutions literally become main branch features......but the guy(s) who make those modifications might not even know what game they are modifying the engine for.

The reason studios have all these roles is because atleast in theory you want the best person for that specific job.
If you have one person that does 10 jobs chances are they are swamped and their work declines or they just arent particularly good at all the jobs.

You cant realistically expect every member of a design team to know the ins and outs of the engine(theres a team for that)........im sure theres people in these studios who have never even launched the editor because they dont need to.
Their role is elsewhere.

 

[Guilty_AI]

Genshin Impact is made in Unity.........I think Tarkov is also a Unity game........I couldnt even imagine trying to make either game using Godot or one of these other obscure engines you think young talent should be learning.

I said Godot was a dead end engine for AAA development (slight hyperbole)
If you are applying to a AAA or AA studio, Unreal/Unity/Cry will look better on your resume even if the studio doesnt actually use any of those engines.

it's newer and growing an userbase. It's also more lightweight, making it better for web-based games and to use in colleges (especially considering it's free), indie devs are also adopting it more frequently, especially after all the fiasco Unity has been through. It's been improving many of it's features also. At the pace it's going, it's just a matter of time before it begins being used in larger projects.

They focus on learning these engines because these are the engines available.
If you come from GameMaker or whatever and apply to ND theyll likely laugh you out the studio because they would be effectively onboarding you for a near full year. (Assuming you arent there just as a coder in which case the engine is irrelevent cuz they would want you to be a good coder first and game designer second).
Having experience in something like CryEngine/Unreal/Unity they will know the onboarding isnt going to be that tough because you'd atleast have the knowledge of how alot of 3D game engines work.
Yes there will be differences, but you;d have the fundamentals.

i don't know what's the exact process ND specifically uses (i doubt you'd enter with just some engine experience, whichever it may be), but learning how to use CryEngine/Unreal/Unity does not mean learning how 3D engines work. Far from it.

Or rather, these are tools designed to let you make games without having to know how 3D engines work, which is exactly the issue i've been talking about.

That is true.
But as I said not everyone wants to be an engine engineer and will make their own game engine.
Many studios use Lua, Python, C++ or C# why not learn game design using an already existing engine that uses those languages.
Why use some obscure engine that the studio may not even know is compatible with how they produce games?

Like i said, this is the job hunting mentality. It's this very same mentality that is causing many of the current games problems. Why learn how to make games properly if it's easier to just learn something that looks better on the resume? Why study different engines, how they work and how to make games on them if saying you have XXX hours on unreal increases your chances of being hired? This is the problem. This is the 'decay' OP speaks of.

At the end of the day most engines work in a similar fashion at this point, which is why you can see talent move from studio to studio and from engine to engine.
They fundamentally work the same (the 3D ones atleast).
The unique features of Engine X wouldnt have been created by the environment artist.....he could have requested the feature but it would almost certainly be an engineer who implements it.
Thats really my point.

Learning how to use X engine =/= learning how they work. All these engines have quirks that if you're not aware of can completely kill your game even if they look similar on the surface. The only way to mitigate these migrations is by... learning how 3D engines work, and proper software engineering.

Wanna an example? Unreal has automatic occlusion culling, Unity doesn't and needs manual baking. Any dev migrating from the former to the latter happily unaware of this will get a few hours/days worth of headache, or worse yet release some unoptimized mess.

Are you assume the proprietary engines work in significantly different ways to Unreal/Unity/Cry?
The experience gained from those engines would be more valuable than experience from an obscure engine that may not even have a feature set thats usuable in todays AA dna AAA space.
Imagine using an engine that doesnt use Normals?
When they give you the tech test youll have no idea whats meant to be plugged in there, you might not even know its purpose?
With the 3D engines available you'd already have a decent idea even if you had never actually handled that specific engine.

Again, learning how to use X engine =/= learning how they work.

If im a modeler or texture artist or lighting artist why should I need to learn software engineering.......ill literally never alter the engine.
The engine engineers and techart will modify the engine according to my needs.
Thats why you have techart and engine engineers.
Even if all I do is program the game logic, I dont need to know engineering for that.

If we want to blame Unreal for something its that studios have stopped putting emphasis in techart and engine engineering and are effectively using stock UE.
So studios should be hunting for those engine engineers who can modify the engine to achieve the vision.......not that we should have the whole studio be filled with engine engineers, thats a 4 year degree.......let the guys who know that shit do that shit......let the guys who are artists or designers be artists or designers.
Its not actually Unreal Engines fault its the studios.
The Coalition modify Unreal Engine enough that some of their solutions literally become main branch features......but the guy(s) who make those modifications might not even know what game they are modifying the engine for.

The reason studios have all these roles is because atleast in theory you want the best person for that specific job.
If you have one person that does 10 jobs chances are they are swamped and their work declines or they just arent particularly good at all the jobs.

You cant realistically expect every member of a design team to know the ins and outs of the engine(theres a team for that)........im sure theres people in these studios who have never even launched the editor because they dont need to.
Their role is elsewhere.

And again, this is what this whole hyper-modular mentality results in.

If you want games that actually feel immersive and whole, rather than something that feels like paper collage, you need these workers who are good at more than one thing or at least have a good understanding of other areas. This is something that even game courses in colleges speak of (though few people actually follow properly)