ORK's Future Plans in regards to Unity - Page 2

I’ve contacted the dev that makes the jrpg turn based rpg framework, but he has no plans on creating a system like ork that allows for turn based and action elements within the same system as ork is. It’s only one system that he builds at a time. I purchased it to check it out but they are VERY expensive, 350+ and they don’t have near the flexibility of ork framework. However honestly in unreal if you had ork working there, I’d be willing to pay those kinds of dollars for your functionality.
So there is certainly a need in unreal that you would be filling and a very active user base. It looks like each of his systems have 500+ people in their individual discords. So thousands of users between them all.
It also solves networking with ork, since network replicating is much more straightforward in unreal. I could easily see ork becoming it’s ultimate form over there.
It’s difficult from the dev side because I’m trying to balance the benefit of changing against the benefit is swapping when the time comes given we were hoping to release in approximately a year. But if you could do that, I think it would be worth the transition for the long term benefits.
So an unreal port would be fantastic.

this is exciting!
keep up the good work!
I'm an excited newbie game dev, that discovered ORK framework recently, amidts this unity fiasco, i created this account to wish you the best with porting ORK to other engines, best of luck!

To clarify the jrpg turn based system that I was referring to is unreal and is the closest thing to what you do. However ork is much more comprehensive. It would be great if you looked into unreal soon too, it would be excellent to be able to use ork in unreal

@gamingislove 10/5ms for the entire 1mil test or an average of 10/5ms per object/wrapper?

I don’t envy you when it comes to the UI part, I’m sure that will not be a fun experience haha

Oh definitely, was just curious if the double in cost was actually something that would worth considering in custom code or not (but if I'm following it right, that's what like 10 nanoseconds an object still?)

Is that for the Editor UI itself, or the ORK - UI object bridge, or is there even a difference? I was thinking about the ORK -> UGUI interfacing part as being a pain given the whole Canvas and various components setup. But I don't think other engines have like 4 different UI systems hanging around either so maybe that helps haha

Looking forward to the changes though, will be fun I think for some personal projects to test porting over as close as possible.

Some good news on that front @gamingislove ive read of a lot of asset devs using ai to translate their c# code to c++ and many of them are saying it’s made the process much easier than expected. It gets it 80-90% of the way there and they are polishing the finer details and error correcting.
Gpt 4 is obviously great for that but there are some very impressive models and frameworks that utilize ai on git that have been recently coming out that make those kinds of processes much easier still.
You’re right that doing it completely manually would take a huge amount of time. However I think it’s at least worth a spike with that tool assisted method given the potential and power of unreal, since it’s probably the next most populous engine, rather than placing it at the bottom of the pile after the others. I personally know many here would be willing to help or bug test in a process like that. On the discords and from my dms it seems like unreal is what approx half of people currently using ork are swapping to :)

Based GiL as always. As far as C# engines go, ones that I come across are:
Flax Engine
Unigine
Stride3D
Godot (Once its C# support gets updated)

My team is moving over to Unreal. Downside is having to translate C# to C++ and adapt to Unreal's workflow. Upside is it would probably be beneficial in the long run due to better project scaling and stability.

Assuming that ORK is heading to Unreal, It'll be interesting to see how ORK is ported to C++(if it's possible). Fortunately, there's Blueprints so GiL won't have to rewrite the visual scripting parts of ORK at least.

A suggestion to GiL: Instead of writing UI scripts for each engine ORK supports, why not create an external Winforms application as the editor? It'll be universal and you don't have to update different UIs for each engine.

That’s fair and quite a reasonable concern; after all you’ve been developing that code base for over a decade.
As far as I can gauge, a viable workaround to that issue is that there are offline models that you can get off git that don’t feed your information back into the centralised knowledge base to avoid it using your code in other contexts. However ultimately you’ve got to do what works with you.
@Raiulyn makes a good point that because of unreal blueprints you can incorporate those instead of starting from scratch. There are a lot of other features that Unity doesn’t have that unreal has out of the box that you wouldn’t have to recode too.
Even at this point it was primarily the main editor and logic for turn based and action that would be amazing. No system is capable of both at the moment in unreal.
It could also answer the request for online support with network replication since that’s one of the biggest reasons to use unreal haha
Either way, exciting times ahead!