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?