I think you’re trying to compare quite different cases.
Changing a single thing in language API is often big change for programmers. Influences the way you work on project, changes needed to be reflected by various compilers and tools. And now programmers can actually take advantage of changes in API. It’s whole different life cycle.
Correct me if I’m wrong, but Apple doesn’t rewrite big chunk of Objective-C every 3 months? They probably spend 100x time on thinking what should be changed than documenting it. It often take years to introduce big change to the market. And then… this feature of language API stays with us unchanged for many years.
Language itself exists for 33 years. Unreal also could be extremely well documented after such time, if every Unreal wouldn’t be very different engine
Although I’m not familiar with Swift, I’m not aware how the development cycle looks there.
But… we always need to consider budgets, number of developers. It’s not like you can’t simply make 1:1 comparison…
Especially that UE4 is ready-to-use toolset where changing single function in single feature can easily go unnoticed by most of the users.
Yeah, seeing this all the time in gamedev
Of course I’d love to use very detailed documentation. I’m with you! And I’d like to be all wrong in this post.
But reality is different. I’ve never seen ideal documentation in gamedev. It’s not only Unreal or Unity problem. And there are reasons for it. It’s not just “developers don’t care” issue.
In gamedev source code is usually the best documentation you’ve got.
Can we finally kill the horse that has been beaten so badly ?
UE4 will never have an official language outside of C++. We have BP which is our scripting language, albeit visual.
You want some other language? Use a third party implementation. Asking epic to provide a third language is quite outrageous.
Why would you ask the developers of a game engine, who are busy working on fixes, adding features, documentation, and making the engine all-round better; to go and to add another language which is just going to inevitably bring more bugs, problems, and less development time for it all?
There is absolutely 0 reasons why any engineer would take the time to add a C# interface when they already have a modern C++ compiler. It’s just completely unnecessary. Adding C# doesn’t solve any major or minor problems that UE4 has.
The only problem adding c# would solve would be to cater to a very tiny minority in the community.
@frankteck UE3 was 11 years old when it had its last update, we can talk about ue5 when ue4 gets another 6 or 7 years older.
BP is very young and even their C++ api is quite young imo. Seeing as there is so much to be added, that in itself is a huge reason i believe we shouldn’t have another language. I mean just look at how far we have come from 4.0.0 C++ code to 4.16 C++ code, it’s night and day difference. They have consistently listened to the c++ users to make it as close to actual C++ than the heavily pre-processor-ed version unreal is.
Yeah, if we ever receive a C# interface, it wouldn’t be anything like the C# in unity, which is what allot of people expect. The engines were designed completely differently.
Allot of people don’t understand that UE3/UDK had unrealscript, a java like language in-addition to kismet a blueprint like system. Both kismet and unrealscript were scrapped so that epic could have central C++ code base and new more powerful visual scripting system. kismet and unrealscript were languages on top of the actual engine source. Imagine having two langue interfaces + a visual system to support on top of the actual engine. That’s allot of documentation and support. in my view epic essentially combined unrealscript with kismet to make a heavily pre-processed C++ that allows us to create visual scripting nodes and editor tools easily and effortlessly from a c++ base. In terms of design, it’s amazing and asking for a C# interface feels like we are going back in time. thats my 2 cents.
That is kind of interesting actually. I wonder if the Slate language will be scriptable from python.
The problem is that implementing just another language costs a lot of resources not to mention that it has to be maintained like BP and C++.
And I really don’t know whats wrong with BP. They can get messy, but so can code.
Users are better off with learning C++ instead of waiting for another language.
The problem is not the language, but the user who codes with it.
[/QUOTE]
Well, I was just saying that it might boost their engine up a bit
