I think of the Soulborn Engine as what powers game's back end, while UE4 is the engine for the game's front end. I don't know how consistent or accurate this is. I do have a sense that the SB is constructed using some ready-made parts and services, so the sense of it as a monolithic package is probably inaccurate. Nevertheless, I believe there must be some unique elements to it that are engineered entirely by SBS for CoE, because some of the design features published don't have equivalents in any other game or service that I'm aware of.

This article talks about the Soulborn Engine. Back then it was called the Proteus Engine

https://chroniclesofelyria.com/blog/2/Dev-Journal-2-Introducing-the-Proteus-Engine

That article is 4 years old.

What is the NEW news on the Engine?

I still want to know if the Soulborn Engine itself is an actual engine, or just a collection of systems in UE4.

It's an standalone engine as far as I know.

Does this link answer your questions?

https://discordapp.com/channels/118109806723727363/118109806723727363/602507675628077056

The soulborn engine has definitely been very vague so far. Annoying that the community likes to use it as a catch-all for any mechanics question there isn't an answer for.

Posted By Avastar at 2:26 PM - Mon Dec 16 2019

Does this link answer your questions?

https://discordapp.com/channels/118109806723727363/118109806723727363/602507675628077056

Banned from the discord, so I'm unable toa ccess it.

Posted By Zeek_Halykr at 3:23 PM - Tue Dec 17 2019

Posted By Avastar at 2:26 PM - Mon Dec 16 2019

Does this link answer your questions?

https://discordapp.com/channels

Banned from the discord, so I'm unable toa ccess it.

Caspian ☁07/21/2019
@Logain Hi Logain. When working on the tools for map generation I moved from TypeScript over to C# to leverage the parallel processing capabilities inherent in C#, which do not exist in Node.js. Node.js is really meant more for creating small, short-lived instances, and is not well suited for long-running, computationally expensive applications that require a large number of objects. Alternatively, Node.js can be architected in a client-server way such that a primary instances is delegating work to secondary instances to perform the calculations. This is pretty common for Node.js, especially in a microservice environment, but is pretty heavy-handed for writing tools.

As for the AI, etc. It was always our plan to port some of our services over to C++ as necessary for performance. It may, given the learning we've done the last couple months, also be necessary to port some of the other services to C# or C++ besides the core simulations around physics, etc.

No decision has been made yet on whether we'll port any additional services to C# or C++. If we did port additional services, I suspect we would aim to keep the OPC scripting service still using TypeScript so we could leverage the visual scripting interface. Sweet! Map N completed successfully. Moving on to Map B.

Posted By Labbe at 3:32 PM - Tue Dec 17 2019

Posted By Zeek_Halykr at 3:23 PM - Tue Dec 17 2019

Posted By Avastar at 2:26 PM - Mon Dec 16 2019

Does this link answer your questions?

https://discordapp.com/channels

Banned from the discord, so I'm unable toa ccess it.

Caspian ☁07/21/2019
@Logain Hi Logain. When working on the tools for map generation I moved from TypeScript over to C# to leverage the parallel processing capabilities inherent in C#, which do not exist in Node.js. Node.js is really meant more for creating small, short-lived instances, and is not well suited for long-running, computationally expensive applications that require a large number of objects. Alternatively, Node.js can be architected in a client-server way such that a primary instances is delegating work to secondary instances to perform the calculations. This is pretty common for Node.js, especially in a microservice environment, but is pretty heavy-handed for writing tools.

As for the AI, etc. It was always our plan to port some of our services over to C++ as necessary for performance. It may, given the learning we've done the last couple months, also be necessary to port some of the other services to C# or C++ besides the core simulations around physics, etc.

No decision has been made yet on whether we'll port any additional services to C# or C++. If we did port additional services, I suspect we would aim to keep the OPC scripting service still using TypeScript so we could leverage the visual scripting interface. Sweet! Map N completed successfully. Moving on to Map B.

Thank you for the clarification.