Hello there !!
Its many years im inside Conan Exiles, and i think a big engine update with these so many feautures that game had, will be simply AWESOME.
Think you will earn also lots of copies guys !
An hug from Sicily,
Vincenzo
Hello there !!
Its many years im inside Conan Exiles, and i think a big engine update with these so many feautures that game had, will be simply AWESOME.
Think you will earn also lots of copies guys !
An hug from Sicily,
Vincenzo
They would have to completely remake Conan Exiles. Maybe if Dune: Awakening does well, that could make an Exiles Remake or even a new Conan game in UE5 feasible.
UE4 isn’t the problem.
It is more than capable of handing the game.
The problem lays secretly hidden within the single threaded phenomenon.
If, (that’s a massively cosmic BIG IF), they even tried going to UE5,
If they use the same crippling agent as this one currently uses …
it won’t make any difference.
All you get is the same “bugs” and no mercy.
So grease up your backside with Vaseline.
The devs have addressed this question a fair few times. To paraphrase Dennis from one of the dev streams:
“Our version of Unreal has a lot of custom work plugged in to let it function in our workflow. Swapping from UE4 to UE5 would instantly create probably a year’s backlog of technical work, and it’s just not feasible to do.”
I’m fairly sure it’s also been said that UE4 → UE5 wouldn’t really change all that much in terms of stability and performance. I’m no programmer, but I’ve heard it from enough knowledgable sources that I can definitely believe it. It certainly wouldn’t be a magic bullet fix, though getting the UE5 lighting tech in Conan would be a nice visual
I’ve been reading about UE5 and the latest Unity drops. I think there is some work to be done to get them to talk to each other, but it was suggested to try. I don’t have the time atm to micromanage it. I’m starting to see articles on it.
OpenXR is going to expect to handle controllers and/or keyboard in a cross-play controller setup. I have the quest 2 controllers. Fun!
Ovviously , is not a stability or bugs update. ( for sure at beginnin )
But will be an insane boost for people didnt play Conan only for " graphics " .
An unfortunatly they are a lots!!
I know the big work will be behind, but , im pretty sure they will sell lots of copies after that.
A well tuned Conan Server performs so much better it feels like a deferent game. It’s not an Unreal issue. It’s a throttling issue.
Example:
Core 0: Server 1001 PVP
Core 1: Server 1002 PVE
Core 3: Server 1003 PVE C
Core 4: Server 1004 (some other PVx)
(FWIW): They could all be running the same play style. Ex: PVP.
Now add to that 20 players on each server.
Multiple and various simultaneous calls.
Each handled by a single thread. (Nightmare)
I think you get the picture.
I don’t. Is that supposed to describe the way you think the game works now or the way it would hypothetically work with UE5?
remember “bottlenecks”.
I remember, but I still don’t know if you’re talking about the status quo or discussing UE5 or what. Is there a reason why that question doesn’t deserve an answer?
There are technical differences between UE4 and UE5.
One of the features is “world partitioning”.
But how good is that in relation to running multiplayer vs single player?
With multiplayer, it still has to deal with multiple clients who aren’t going to be on the same area of a map.
It boils down to an existing problem we have now even on one map.
Yep. The world partitioning makes it possible to have larger levels without dividing them into sublevels. Instead, they get streamed in and out on demand.
What world partitioning does not do is partition the level and assign different partitions to different cores or threads. It’s not sharding.
It would be cool if it did that, but it doesn’t. Probably because that’s an idea that sounds great in theory, but turns out to be a huge can of worms in practice.
You’re right about the bottlenecks, though. That’s why no one would do what you described in your example. Even if you took advantage of NUMA and it all somehow worked out perfectly – and it wouldn’t, but let’s assume – you would still have the same performance problem the game has today. Sure, in that hypothetical “perfect” scenario, you would be able to have N servers on the same machine, but each server would perform as badly as a server does today – at best.
Multithreading isn’t magic.
Multithreading is actually fiendishly complicated for some workloads, which includes games.
While some people like to think their hardware is poorly utilized or that game devs suck, the reality is that the single thread bottleneck is there for a good reason, and is not going anywhere. And even in the games that do load many threads, there is still one thread that is far more heavily loaded than the others. Always. Think of it as the master/game logic thread. Absolutely critical for the game to function.
The thing is when playing a real time 3D game (in particular), there are serious timing constraints than you will not get with most applications, so you cannot compare things that easily. Also games need to use a lot of sequential tasks (you require the results of the previous calculations to make the new one), which does not lend itself to parallelism.
If you split a workload between threads, you’re adding delays, potential new bottlenecks (communication between the threads) and all of that needs to stay perfectly synchronized, in the case of a game. Basically you might lose more than you gain if you split the wrong things
Finally, someone talking sense. I was starting to lose my faith in humanity
That single thread can easily bring fibers into discussion, and correct the above thinking. That is the CRTL, you want… unless your code doesn’t use any of it. (That’s the C runtime that runs in its own context outside of fibers.) Visual Studio is aware of it, so it can be debugged easier.
I’m not in any way suggesting eliminating single threading, nor splitting up of them. (That would be begging for more trouble).
I understand its’ critical functionality.
What I am saying is that this game is crippled by the exclusive use of it.
Especially when other functions would be better served by their own threads
outside of that restrictive, linear box. Such as players in different areas of a map.
The way I’ve understood this, is everyone regardless of location or actions are irrevocably chained to a single thread. (first come, first served). Everybody/everything else is forced to wait in line regardless of how fast the line moves along.
Am I mistaken?
Using the same paradigm in UE5 would only produce the same headaches.
Edited for Grammatical Correction
Indeed. Yet i don’t see Conan exiles 2 on Ue5 but on Ue6.
A hug from Rhodes too, brother, welcome to the forum .
There is no doubt that Conan servers could run better, and I am sure some tasks could be offloaded to other threads, like NPC AI is usually a good candidate. But it is really hard to estimate how much that would help, without rewriting the whole game. Evidently a lot of bad decisions were made along the way. I mean, we already see the NPC AI freezing when there is enough players online, so I imagine they made it very low priority… offloading it would not make the game feel much less laggy perhaps, but it would ensure that the NPCs function, which is… something.
My understanding is that big multiplayer games using the Unreal Engine (and similar) basically need to use fully custom code for their server executables, if they want good performance, because the basic server code it ships with is typically only suitable for a small scale pvp shooter (such as the cancelled Unreal Tournament title, if speaking of UE4). If your game differs much from that template, you’re going to have a bad time, and that’s exactly the situation with Conan since Funcom didn’t have the knowledge/experience for such things. Swapping to UE5 would help Conan servers very little, if at all (but I am sure it offers better client side visuals though).
I do not think any game in existence splits the handling of players between threads the way you describe it, for one single map/instance. The reason is that it’s not as trivial as it initially sounds - one thread might finish things before the other (and thus get stalled), or the calculations produce a different outcome (just think about the RNG elements in many games), and suddenly you’re totally screwed when anything happens around the edges of the map areas, where players who are handled by two different threads meet up. Which thread is right, which thread is wrong? Or are they both right? Or you have a master thread who calls the shots, but then if a lot of activity happens with players from different shards… you suddenly find yourself with a new single thread bottleneck.
Fibers only work in context of a thread. If two players are on then there are two threads still with many fibers. The “main” thread handles it with fiber management, which would be easier.
That platform exists. Built-in serialization is helpful, but there are better ways to get two threads with many active fibers to talk to each other by ordinary means.