Okay but Martys RTGI is great and works in quite alot of games without much tinkering (just need to access depth buffer), don’t mind paying for it. Useally sub and let it expire once every few years.
The one thing Unreal still has bug wise is the fact I can’t place hundreds of actors in a blueprints viewport because it lags like Satan but if I run code that spawns the same amount attached to said actor or drag the same quantity into the level itself it works without issue.
I think the hardest thing to do is having complex facial expressions overlapping when characters talk. You could do face capture for every dialog option but that would be a massive task.
In alot of engines characters mouths are controlled by a lip sync system that uses, pitch, tone or text fed dialog to ‘mimic’ words being formed in the mouth. It’s far easier to have that and then having facial expressions as a separate animation layer that’s blended together and triggered based on a enum that’s selected by a script (say a players dialog option says “Your a mean man” and the player selects it, the NPC knows what you selected and in that dialogue option theirs a little enum (it makes more sense if you treat a dialogue option as an object) that contains the facial expression or expressions that are appropriate to use in response).
Full facial animations are used mostly for cutscenes because actors cost money while in game is just the engine trying to move the mouth using code (I know Farcry 5 had this where only the important characters had full facial animations and the rest just flapped their mouths up and down).
With nanite, live coding and lumen Unreal is unbeatable at the moment and lots of studios are hiring like crazy for Unreal Engine specialists to try and beat the competition.
If CDPR wants to compete they’ll have to do a ton of work making those tools for designers and artists easy to use (alot more in-house engines still have source 2 hammer editor style toolkits and command line conversion tools which are shit compared to Unreals drag and drop advantage).
Plus Unreal 4/5 was built to be as modular as possible so you can build whatever you want while CDPR engine was built specifically for this genre of games Cyberpunk is in. They definitely could and I see the engine having potential but afraid that’s it’s not flexible enough without serious work.
They had some kickass developer streams on YouTube. I still remember when they were playing Saints Row 3 and (I think it was the lead designer) being amazed that a helicopter had an interior texture for the cargobay even though 99% of the time you wouldn’t see it. Also skinballs and how they used markers to determine NPC behaviour out in the world.
Also the horror story of how they spent weeks compiling visibility volumes for Saints row 1 and having to satisfy silly requirements set by Microsoft such as having a game trailer play on the title screen if no input was detected for a set period of time. They just played a video of them playing the fucking game so they didn’t have to do any cinematics lmao.
The Red Fraction Guerilla stream was extremely interesting. How they managed to make destructible buildings and the limitations of that system. They used a stress mechanic that used key parts of a buildings frame to determine how stable it is (can’t remember if they used vertex weighing or not).
But unfortunately the most talented on the team didn’t get much of an input of where the IP went
Modern game engines are extremely complex machines, starting from scratch would take decades because it’s fundermental things like drawing geometry in a 3D space, getting input, memory handling, garbage collection and all that low level stuff that needs to be re-done. Physics requires lots of work, so much infact for a time HAVOK was the go to plugin for most engines (still kinda is) just because of how God damn hard it is to have nice physics and high frame rates (tried to build a physics engine from scratch in C++ and I couldn’t get past the floating point position problem so anything too far away from 0,0,0 would spaz and handling multiple collisions on an object simultaneously caused all sorts of freaky things to happen).
Then when that’s done you still need to write additional tools and plugins so developers can import assets and scripts into the engine plus a level editor for designers to place objects, triggers and all that fun stuff.
After that you can now start making the game.
Bethesda probably rewrote huge chunks of their engine to support larger texture sizes and improve performance across the board for Starfield.
If they do decide to dump it then they’re most likely to use an existing engine like Unreal or Cry rather than build one from scratch.
Personally I believe the reason why they didn’t re-write the character movement is because it would also mean altering way to much stuff on the front end.
A good example would be if I use FunctionGetVelocity in my script to determine if a player is moving and it use to return an int but now it returns a float because of the rewrite, without conversion would mean you’d probably get a crash.
Another example would be AI related. If I use a variable to get a rot data type but now that’s been replaced with a struct that needs to be split to get rot now suddenly you have to touch the code to make it compliant.
I mean if its just playing it normally and not proper testing (run there and jump while spamming the inventory key until the game breaks kind of testing) then that’s a pretty sweet deal