What I'm saying is that a professional game dev studio that can't make their own engine should probably not be making games.

I understand the phrase. But because game engines are not even close to being perfected we need people to learn how to make them so they can be reinvented. Because what we have today is nothing. It's clunky as hell. Like a square wheel. Game development is still in its infancy and there is a loooong way to go. And we won't get there any time soon (or at all) if most of the industry is dependent on the work of others and the knowledge is not passed along and innovated upon.

Good ole Riccitiello continuing being a blight on the gaming sphere. This just seems like an extension of Unity's prior business decisions in recent years. Will be interesting to see what possible backlash the company will receive for this newest boneheaded decision-making. If they want to crater their dev-userbase this is certainly a good way to do it.

If you're dealing with bare hardware and a fixed set of hardware i could agree with you. But again we're not.

But why do you feel it's necessary for them to build/maintain their own engine? I mean if it was something brand new where the engine didn't exist (say DOOM or Quake of old) then sure. But today's engines handle that quite well.

Then you have games like Visual Novels that... just don't need a whole lot of power to run.

If the engine is lacking something, sure. If someone wants to build an engine for the heck of it (or provide the first port of say GL Quake) then sure. But the process isn't straight forward. This isn't a single thread MSDOS system world anymore that doesn't require drivers and problems are easy to spot; And some things like even the C++ language can obfuscate and inject bugs to perfectly properly looking code. You can literally pull your hair out for weeks trying to find bugs.

Why should i have to build a piano when all i want to do is play music? Well now if you can't build a piano then you are a terrible musician and should just quit music altogether. That's what i'm getting from you.

While i think it's nice to understand how the piano works, it's a black box, meaning you put something in, and it gives something out, and that isn't required to make music. Understanding under the hood to optimize is one thing, but your approach i feel is wrong.

Many game makers today aren't programmers, and never will be. But with tutorials and tools given in say Unreal Engine, they can find models, animate them, and even attach in a visual programming-like way for how something should work, and build a game. And using RPGMaker and the default programming in place, you can make your own Final Fantasy story of getting the maguffin and fighting the final boss and throw in some pictures, and have a sufficient game.

Often times artists aren't programmers, and programmers aren't artists. And the ones that can do both, well they should be appreciated. But someone making a multiple choice novel shouldn't be excluded from making a game using RenPy just because they couldn't make their own engine.

Uh...are you implying writing an engine for more than one platform is somehow way more complex than for one? Cuz, it's really not. Look, you don't get it and that's fine. It's not that important you understand.

Yeah, like that little company that makes unknown games like The Witcher and Cyberpunk. Clearly they have no idea how to make games, so they have to use Unreal Engine. How silly of them.

Why were you warning about it, ie. why did you see it as a problem?

Was your suggestion to switch to Unreal Engine, ie. it doesn't have similar issues? I am not quite sure what are all the viable (3D) game engines nowadays, especially for people who'd like to release their game both on PC and consoles.

The recent news of Cyberpunk not receiving new DLCs after Phantom Liberty due to CDPR switching from RedEngine to Unreal Engine (hence no more content for e RedEngine Cyberpunk), it occurred to me that is it now a trend that pretty much everyone will develop their games with Unreal Engine, and especially the idea of developing and maintaining your own (3D) engine in this time and age is dead idea? Like back in the day CroTeam developed their own 3D engine for the Serious Sam games, or CDPR developed RedEngine, but nowadays the technical needs for the platform and support for different platforms (including consoles) is so hard to maintain that it just isn't feasible anymore?

What does that mean in practice, which are the (3D) engines that will remain viable (Unreal Engine, Unity, any others? Someone mentioned that free Godot? The odd thing is that I thought Unity is a free game engine, but apparently it wasn't...). Will games start look more and more alike due to using the same engine, or is that irrelevant to how the game will look like? Will the Unreal Engine become too powerful "monopoly" if everyone flocks to it?

I recently tried out Dishonored 1-3 games, and I kept thinking does Dishonored look so much different from 2 and 3 due to using a different engine, or is that irrelevant and it is merely due to different artistic choices when making those games? (I learned from here that Dishonored 1 uses a different engine than 2 and 3, and 2 and 3 indeed look quite similar to each other, but quite different from 1).
I wonder if CDPR will at some point release a remake of Cyberpunk, using the Unreal Engine? Maybe when the next console generation arrives?

Do you mean decent games like Witcher 3 & CyberPunk? That used their REDengine? How do you credit that to Unreal?

Anyway, no one is saying a group knowledgeable enough to write their own engine can't use unreal and make a decent game with it. It's not like Unreal is bad. Unreal is amazing. What's bad is not knowing how to do any of this stuff yourself.

Depends on the language, depends on the tools, depends on the approach. I don't want to see tons of #define #undef blocks that get so cluttered you don't know what's going on. And when you are doing multiple threads programs can crash because it didn't get a reply data from another thread in time, and there's no way to debug that, or requesting memory and not getting it then segfaulting (since checking and handling errors are often ignored in C/C++)

I'm saying, unless you can clearly and consistently plot exactly the exact path of execution, and you know exactly what every single call does and where it leads, you will have issues. Writing to the memory buffer from B0000-C0000 is entirely different than trying to write to some other hardware that may or may not use 3D acceleration, that may or may not be in different 32/64bit memory locations, that may or may not be using 32/64bit code, that may or may not have sufficient ram or VRam, that may or may not have CUDA or other chips, that may or may not support the resolution you are trying to work with, etc etc etc.

Many 8/16 bit use sprites, you program the sprite, then you specify the location (possibly scale and rotation) of the sprite, if the hardware supports it, it can even tell you when there's collision. It's a handful of documented things to worry about. Or at the last the hardware and interface is going to be within a set and won't change between OS or Manufacturer of hardware.

Why do you think OpenGL and DirectX are a thing? It takes most of that and puts it in a black box, you make requests and it handles it, and you worry about important things, like models and textures, game logic and music. But that's also part of 'the wheel', that makes up the engine. And even using that, the OpenGL reference books are HUGE! I'm quite sure you don't know the scope of what will go into an engine even using the usual frameworks.

A list of game engines which are suitable for cross-platform (including PS5 and the newest XBox, whatever it is called, XBoxTwo or XBox720?) AAA-releases would be maybe more useful, making engines like Adventure Game Interpreter, Adventure Game Studio or Aleph One irrelevant in that vast list.

No, existing games are not affected. Changes like this one only affect new releases.
But yes, it would have a massive influence on new releases if we insist on games running completely offline.

It appears you've dabbled in programming. But the more you talk about it the more clear it is you don't understand it very well.

Because CDP has switched to Unreal. They're not using their own engine anymore. According to you, they don't know how to make games:

Maybe he is referring to the recent news that CDPR is ditching REDEngine, and switching to Unreal Engine for their future projects. Which also is the reason Cyberpunk will not apparently receive any more DLCs after Phantom Liberty.

Apparently they felt dealing with the issues with REDEngine, especially on consoles, took too much effort and caused too much problems on Cyberpunk's release. They rather concentrate on developing the game, rather that dealing with the engine issues.

Probably. But they are a team that has made the bulk of their success so far based on their own engine. And we don't know who made that decision. Was it the devs or management trying to show share holders they are making changes so a CyberPunk launch won't happen again?

Anyway, I'm not saying a group knowledgeable enough to write their own engine can't use unreal and make a decent game with it. It's not like Unreal is bad. Unreal is amazing. What's bad IMO is not knowing how to do any of this stuff yourself.

And if you look at GOTY stuff it's like Witcher 3, Elden Ring, Baldurs's Gate 3, GTA, Skyrim, Zelda BOTW etc. What they have in common is these are all in house engine titles. So they were made by people who actually understand how games are made.