Discussion Unity and more widely open source availability

There was a short discussion about Unity source access in this thread (link to the first post in the conversation), and I hadn't seen any dedicated discussions about the topic lately, so I thought this could serve as a central place to talk about it.


Current state

Unity is written in both C++ and C#. The C# side of the engine has source code available for reference (viewable here), but not editing; you cannot make changes and recompile it into a new executable without using tools like Mono.Cecil. The C++ side of the engine has never been released publicly. As of October 13, 2022, read-only source is available to Unity Enterprise customers by default and to Pro customers as an add-on. It's not clear if either of these options also include the ability to modify the source and recompile, or what the cost is for Unity Pro customers to purchase access (I assume it is on a case-by-case basis).


Source availability vs. Free and open-source software (FOSS)

Software that makes its source code available is not necessarily without constraints. The widely known MIT license (e.g. curl) is very liberal in this regard, allowing anything from modification to redistribution of the code and software. The GNU General Public License (e.g. Blender) is a bit more restrictive, requiring developers to make any modifications freely available. At the other end of the spectrum is Epic Game's license for Unreal Engine's source code, permitting modification but heavily restricting redistribution and requiring royalties to be paid for any product using any part of the code (more on Unreal later).


Why does having source access matter?

While the most obvious benefit to having source access is the ability to directly modify the behaviour and expand the limitations of a piece of software, this is not the only way users can benefit from source code availability. Unreal's FAQ states it nicely:

Being able to read through the source code of a tool immensely aids in your understanding of how it works and what its limitations are. This can hugely speed up the process of debugging, profiling and make it much easier to evaluate whether something will or will not be capable of being able to solve a specific problem.

When this knowledge is shared, it elevates the community's understanding of how the tool works; queries about the functionality of internal modules can now be answered by any member of the community who has read the code, rather than only internal developers themselves. As well, once the community has source access, it opens the door for contributions back into the codebase (more below on how Unreal handles that).


Case study: Unreal Engine

Unreal is probably the tool most often compared to Unity. As stated above, it freely offers the engine's source code to all members of the community (i.e., people with Epic Games accounts) for viewing and modification. You can read more in-depth about their license in the Source code section of their FAQ, but to summarize:

and

Developers are also limited to only sharing code snippets under 30 lines in public forums.

The code is available for viewing when you create any project in Unreal. Ever wonder what happens when you try to destroy an Actor (the GameObjects of UE) in Unreal? Simply right-click the function call and Go to definition... (or, if you are using Unreal's visual scripting tool, double click a Destroy node to automatically open Visual Studio to the source).

Code (CSharp):

1. bool AActor::Destroy(bool bNetForce, bool bShouldModifyLevel)
2. {
3.     // It's already pending kill or in DestroyActor(), no need to beat the corpse
4.     if (!IsPendingKillPending())
5.     {
6.         UWorld* World = GetWorld();
7.  
8.         if (World)
9.         {
10.             World->DestroyActor( this, bNetForce, bShouldModifyLevel );
11.         }
12.         else
13.         {
14.             UE_LOG(LogSpawn, Warning, TEXT("Destroying %s, which doesn't have a valid world pointer"), *GetPathName());
15.         }
16.     }
17.    
18.     return IsPendingKillPending();
19. }

Complete with the original comments.

If a user makes a modification that would be widely useful, Epic Games takes pull requests to the codebase (see the Contributions section of the GitHub repo) and has a page dedicated to helping developers make quality contributions.


Why should Unity make their source more available?

Unity is filled with many small and large annoyances that could potentially be resolved by giving primary stakeholders of the engine (the developers) the ability to fix these problems.

As well, Unity is already moving in this direction; despite the C# side of the internal engine code not being available, a huge amount of Unity’s newer modules do make their source available through the package manager (as @MelvMay notes in this post). This includes some of Unity’s largest and most complex packages like the ECS framework and Unity Physics.


Examples where I have used source access

• I modified the InputSystem to be capable of interacting with multiple EventSystems simultaneously for my VR vs. PC project (as with local play, the PC and VR players can interact with the same menu independently).
  
  
• I integrated ProBuilder's internal Box Projection mapping function into my project's build pipeline to generate projected UVs for non-ProBuilder meshes.
  
  
• For my website, I needed a code highlighter that would allow me to highlight segments of individual lines, something that the tool Eleventy (the site generator I use) was not capable of. I was able to implement this functionality by reading through Eleventy's source code and creating a modified highlighter.
  
  
• Our project uses Photon Fusion for networking. At build time, Fusion registers all network objects in the scene and spawns them at runtime--including disabled objects. This was undesirable for my team, so I was able to modify their editor script to include only enabled objects.

Arguments against Unity moving to a move available source model

As seen with Unreal, there's a lot of work that goes on around making your source code available. The licensing and legal side needs to be managed. Documentation on how to access and build the code needs to be written. Handling pull requests properly requires best practices to be laid out and developer time to be allocated to review and merge contributions.

I do not have access to Unity's source code, and so I do not know how much work would need to be done to make it easily buildable by external users (I assume at least some of the work is already done, since as noted above it is currently available to some customers). I also am not in the business of building game engines, and so cannot comment on the legal or financial side beyond presenting Epic Games as a precedent. Obviously Unity's revenues from selling the source access would be affected, but I have no idea if that income is substantial or not.


To conclude,

I probably don’t need to note that I’m a big fan of source availability when working with tools, since having source code to me means the removal of limitations; we can look at the fantastic work that has been done with the Mario 64 decompilation project as an example. I’m interested to hear other perspectives on the topic, and if anyone has any corrections to make to the above please do so, as I’m certainly not an expert in software source licensing and whatnot.

 

As I see it, here's the big problem with Unity's current lack of source code access:

1. You encounter a bug with the engine. It's a simple bug and the fix only requires one or two lines of code to be changed.
2. You really want to fix it yourself so you can move on with your life and the project, but Unity does not allow this.
3. You make a bug report.
4. Two months later, you get an email from Unity that they have investigated your report, confirmed that it's legit, and are maybe thinking about possibly fixing it.
5. Two years later, there's finally an LTS version of Unity that has the one-liner bugfix integrated.

This happens to me very frequently, especially when I'm working with more obscure engine features. I spend TONS of my precious development time figuring out messy, hacky workarounds for Unity bugs because I have no ability to fix them myself and waiting for Unity to fix them is impracticable. I wish I could instead spend that development time fixing the underlying bug, for me and also for everyone else who uses Unity.

Furthermore, the lack of source code access makes it very difficult to understand how engine features really work, especially for parts of the engine that have minimal or missing documentation. Sure, the C# code is available for reference, but >50% of that is just external calls to the private C++ code!

I am seriously considering switching to Unreal or Godot for my next project, and that's almost entirely due to the full availability of the source for those engines. I'm so, so tired of working around and against Unity's closed-off codebase. It feels so F***ing pointless.

 

Counter args - "Developer" fiddles with source code many times. THEN he introduces a bug that under certain conditions introduces catastrophic failure. That failure was dependent on some other code they fiddled with prior...maybe... "Developer" then inundates Unity with bug reports. Developer doesn't have a clue and Unity is supposed be his personal tech support? Not a good business model all altruism aside.

 

Well "Developer" should always test their bugs in a clean environment, if in doubt!
And if the issue keeps occurring, even in a clean Unity Version, only then inundate Unity with bug reports!
Capish?

 

Easy fix: require bug reports to contain sample project without any source changed.

I did it many times where my big project with a lot of packages changed had Unity bug and that was the only way to be 100% sure.

 

The only counter argument to not distribute the source is the paywall that exists today to access it, which IS an acceptable argument (this may be one of their main source of income, who knows). But nothing else makes sense to use as counter argument.

So the question is: is it doable financial-wise?

 

Obviously, source access will do only good for the engine in the long run. But do we actually expect to get any sort of answer here from unity except polite "won't do, sorry"?
It is usually unity devs who browse these forums and if they could go open source, they would do it long time ago I'm sure.

I'm gonna contribute though to the list of stuff source access would be nice for
- I hate built in object picker so much, I used Harmony2 to modify source of object field
- With newer graphical APIs, NativeRendering plugins become practically useless (case 1, case 2) unless you know more about internal structure of the engine
- I would very much like to have heightmap collider exposed properly instead of TerrainCollider, which is annoying to work with because it will create heightmap texture no matter what (Actually all of terrain in unity is just a joke that has to be replaced)
- No way to get directional light projection matricies! SRP code has method to do it, but its stupid placeholder, and they actually mention in C# source that they should replace method in future (it accepts light index and culling results (??) instead of reference to light itself)
- Runtime access to animation clips! Custom nodes in animator!
- In general, unity's design leads more to being bunch of APIs and unlike unreal, we don't have "the unity-way" to do things. You kinda just make "your own version" of the engine during development. Which is not necessarily bad, but in this case source code is even more desirable

 

They could still sell it but with more reasonable price (price increasing for every dev or 1% rev share etc). I think the main counter argument is that they are worried of someone stealing source code but let's be honest:
- Unreal does a lot more next-gen features and aren't scared
- someone that would benefit from stealing source code probably have enough money to buy it already

 

Think I remember some dev saying why this is neigh impossible: The C++ side contains stuff that is under foreign licences. They have a monetary agreement with those licence holders to allow sharing the source with paying customers but they could not afford a licence that's open for everybody (any licence holder in that position will charge a ton from Unity and Unity cannot really hope for a jump in revenue from that step since the customers who have money already do pay).
So fear this wish and argumentation in the thread is a bit fruitless...

 

I am strongly in the camp that prefers source access but I'm painfully aware there are a two reasons that make it quite unlikely for Unity to change their current status quo regarding their C++ source:

1) Unity uses a host of licensed 3rd party tech (eg: Umbra, FMOD, Enlighten) they can't just broadly give access to by flipping a switch because it require signings papers and going through pricey bureaucracy. BTW, Unreal and CryEngine had the exact same limitation before UE4 and CE5.

2) Allowing anyone to recompile the engine would make it harder for Unity to enforce their subscription policies: people could just compile out all licensing and tracking stuff and go their merry way.

 

FOSS in unity is not happening. THe point of FOSS is to allow other people to take your work and use in their projects for free.

Unreal is not opensource, their license is quite restrictive. For example, you're not allowed to post a whole lot of code online.

Also, unreal source code is not rainbows and sunshine. Just because you have source code access, it does not mean you'll be able to learn from it, fix it or make sense of it. A simple method can go elven levels deep and jump through multiple components, and if you realy on its inner workings you learned through the code dive, then in the next update things you used might end up destroyed, refactored away, or completely changed. Everything you see in the source code is undocumented functionality and is subject to change. What you can be sure of is public-facing API.

 

Note that this discussion is not intended for Unity to move to a FOSS model, but rather using Unreal as case study (I make note of the restrictions on Unreal's source licensing in that section of the initial post).

I agree that is a challenge with working with large, old codebases, but this is a hazard around making use of any source available project, including modifying any of the C# Unity Packages (I use the Needle mirrors on GitHub to pull in changes, but you are pre much required to test and vet it when you upgrade). Even with those steps, I still really appreciate having the ability to modify the code, and understand it more deeply.

I've seen this mentioned a few times, would be nice I suppose to have an official reply on it. How did UE and CE solve the issue? Via reaching a deal or just replacing those components with proprietary code?

I wonder how Epic handles this. In Unity's case, you can of course just not pay the license fees and wait for them to audit you, so I'm not sure if removing that kind of code would serve much purpose (unless you really, REALLY don't want the splash screen).

 

UE4 source pretty much doesn't have any code related to consoles

I heard that they specifically made UE4 without third parties for the sake of source code, and also that UE4 development started in like 2000s, took about 10 years

For all we know, Sony could sue Unity for having even hint at how PS4/5 work. Like having specific branch with comment mentioning PS4 architecture might be enough to break their licensing.
All the more reasons we should get Unity6 instead of yearly updates if you ask me

 

I don't know how you came to that conclusion from that. All that line is saying is that you need to be a licensed for the consoles. Once you have the licenses you simply contact them and they provide download links to the source code for the consoles that you have access to.

 

Ah, the weekly why garbage Unity isn't the wonderboi Unreal thread on the General Discussion.

 

Like I said... "it is not rainbows and sunshine", and in your case the case study is a bit one-sided.

People bring up source code access as if it was a silver bullet that magically would solve every problem.

I'd like to stress that the situation goes beyond "challenge of working with old codebases" and put it into perspective.

Codebase of UnrealEngine is over 300 megabytes of code. You won't "understand" it at any given time. The main issue is that the moment you dive below the official API, you're in No Man's Land, which is unsupported and in constant state of flux. So you dive in, see something, assume "Aha, that's how it works", and t he next release they might scrap the whole thing you were relying on.

For example around version 4.12 of Unreal Engine I needed something basic like making pathfinding control root motion. At the time I was quite surprised to discover that pathfinding code is spread through seven different components, hijacking it was an interesting adventure, and then once I made root motion work, in the next minor release they altered the part I relied on, breaking the code I introduced.

The interesting thing is that Unreal has been slowly copying Unity's practice. For example, originally C++ documentation was trash and did not exist at all. That slowly started to change. Originally the site did not host archived API references for previous engine versions (that was fun), only latest was available. That also started to hcange.

The point is, while code access would be nice, it is not strictly necessary, and documentation might be more mportant. C++ bindigs would be nice, though, and those could be provided without source code access. See how 3dsmax/maya originally handled 3rd party plugins, for example...

 

In the end Unity does strive towards more openness. A bunch of components have been moved into packages after all and those are automatically open source and can be edited. No direct way of contributing sadly, but it is something.

 

Yes. It's not just because it's a revenue stream (licenses in general are less revenue than services and advertising), but because there are multiple licensing issues that would have to be overcome before source could be made accessible in the first place.

This whole idea that the source should be widely accessible rarely touches on the reality of the situation.

 

Just open source the C# side is fine for me. At least I can debug and fix bug that was really in C# side. It also possible to upgrade some parts that was not really need to be C++ and skip over to write in C# if there is a bug in C++

Especially the editor code and build process that really just extend in C# and could just call C++ code only where it needed

Eventually I wish unity would purely be written in C#. Today C# are performance enough and there is also NativeAOT and many functionality that can make C# as fast as C++

On the other hand I am curious if there is foreign licences thingy, how they can sell the pro license? Or is the license just charged unity for the number of accessor?

 

Different business model. Unless you sign for a custom license, you owe Epic 5% of the yearly gross revenue past 1 million USD generated from software distributed to end users using Unreal Engine code. It's hard to stay under the radar if your product hits that much revenue.

 

The license agreement allows them to distribute the precompoled Unity player using that tech, not the source code and actual libraries. Just like we can distribute applications made with Unity, but not the Unity editor itself.

 

Yeah, they don't realise that Unity would still be garbage, even with source access.

 

You misunderstand what I said. The point is they can still expose the source code to the one who pay the pro license. So the original source is not strictly prohibit this

 

I don‘t want and don‘t need the (c++) sources. Seriously, this would be absolutely intimidating stuff and a pain to set it up just so it compiles. I wouldn‘t even bother doing that. The only reason I might do so with Unreal would be because it has no other (serious) means of programming in it. And I would hate it!

I‘ve very, very rarely ever had any need to change the code. To some degree I wish I could look at it so I know what it does but not in order to change it but rather finding alternative solutions.

 

Most if not all Unreal engine users benefit from the community pull requests. You don't have to personally do a thing with the source, it's the concept in general. Openness leads to more stability because it enables users to address issues the company in question might not consider high priority or are too busy with other issues to address in a timely manner.

That said, I doubt it'll ever happen. Unity's management is highly profit oriented. This would entail a lot of extra cost with no revenue even if the result would be a more stable engine.

 

And? You still have a choice in Unreal whether to fix the bugs you encounter or extend the functionality of the engine and whether to merge with new releases or not. Which is something that you do not get from Unity for free.

Unexperienced developers would still use binary releases and not touch the engine source code, more experienced ones could benefit from it.

 

I would be happy if all Unity teams that manage packages have a unified criteria and:
- All packages, which are the ones with C# code, are publicly available on github.
- Allow to create issues, read them and answer them.
- Allow PRs to be created, answered and accepted.

The reality is that if we don't even get to this point in the new code (= packages), it is hardly going to be possible to do it in the whole c++ part which is the most legacy / technical debt part.

Right now:
- Depending on the team that manages that package they have one policy or another: some have them publicly on github and others don't, some allow to create issues and others don't, some allow to create PR (InputSystem) and others don't, etc...
- In the repositories that allow to create issues, the reality is that most of them are not even read... In other repositories they invite you to use the forum which most of the teams don't even look at or answer... In others they invite you to use the usual bureaucracy of the issue tracker and the frustration of waiting months for them to solve it...

Examples of how they work in different repositories.

Input System

The issues must be reported with the usual bureaucracy of the issue tracker but instead if they allow and accept PRs but they have a bureaucracy that does not allow to merge the PRs directly but it seems that they have to do branch engineering:

https://github.com/Unity-Technologies/InputSystem/blob/develop/README.md#contribution--feedback

https://github.com/Unity-Technologies/InputSystem/blob/develop/CONTRIBUTIONS.md

Mobile Notifications

Issues have to be reported with the usual issue tracker bureaucracy but they do allow and accept PRs:

https://github.com/Unity-Technologies/com.unity.mobile.notifications/blob/master/README.md

https://github.com/Unity-Technologies/com.unity.mobile.notifications/blob/master/CONTRIBUTING.md

This repository does not allow to create issues but it does allow PRs although there are cases that have been waiting for 1 year to merge:

NavMeshComponents

https://github.com/Unity-Technologies/NavMeshComponents/blob/master/README.md#bug-reporting

https://github.com/Unity-Technologies/NavMeshComponents/pull/198#issuecomment-762158471

uGUI

It allows to create issues and PR but they don't even look at them, there are issues of more than a year without response:

https://github.com/Unity-Technologies/uGUI/blob/2019.1/README.md#will-you-be-taking-pull-requests

 

That's because you have to sign a contract and pay money for it (some of which is forwarded to the licensors). Enterprise licenses already involve actual contract signing, and the Pro licensees which purchase source access need to go through a similar process (and pay extra).

 

Right. One thing I think unity company should do is utilize more github instead of focusing on using their own error report + issue tracker + feedback site and package document

github markdown also easier. we could just ` and ``` with syntax highlighting

 

Maybe Unreal/TenCent wouldn't need to send sales reps over here with a wall of sales pitching, like the way too high effort original post, if they had a huge community of resources and a good set of manuals like Unity.

 

By the way, I sort of wonder how many people realize that fixing bugs you encounter in someone else's product means doing unpaid labor for them.

Anyway.

While source code access would be nice it is less important than quality docs or adding C++ bindings. The reason for that is that stuff under the hood comes with no warranties whatsoever and is subject to change. Which is quite different from public API that is documented.

 

Well, at least I can do that unpaid labor, which is something I cannot say about Unity.

 

As opposed to what? Getting blocked indefinitely and giving up? Or spending that time or even longer to work around Unity's bugs? That free labor contributes to the quality of life of all users, including your own team.

 

As opposed to making a workaround. You still are going to vastly benefit due to building on top of unity rather than making your own thing from scratch, as unity saves months or years of work. With a source dive you'll be doing someone else's job, and you'll be doing it inefficiently. Because a unity engineer will know codebase better than you do, and you'll waste time getting acquainted with it.

Source-available licenses which allow user's contributions kind put the company into a strange position, because the code users submit will belong to the company, while contributors will not be getting paid. That in turn gives an incentive to develop a dubious relationship with userbase where the company would promote source availability, tout their product as opensource, accept contribution, pay nothing for the work done by the users, all while keeping the right to the project to themselves. Oh, wait on top of that users may end up paying them for the work they did for betterment of the engine. Because you can be subscribed to pro and still make submissions.

Is this sort of scheme even right for a commercial product? I'm not sure. It doesn't smell right to me. The way I see it fixing a commercial engine is not a job of the community or unpaid volunteers. There are people getting paid salary for this.

Spoiler

You can think about this way. Imagine that you went to an expensive restaurant, did not like the food, so you went to their kitchen, cooked the food yourself, ate it yourself, and still paid to the restaurant. Does that make a lot of sense?

That's basically what people are trying to do by askin for a way to fix unity's bugs themselves.

Do not forget that at the end of the day Unity is still a commercial product. And you're the customer.

Were unity truly FOSS in the first place, that would be a very different story. But it is not.

A much better idea would be to develop better responses to feedback, better response to bug reports, and so on. :Like I said, there were many examples of successful APIs and libraries where source code is not available. One example is DirectX itself. You never need to dive into it. Other examples are 3dsdmax and Maya, though it's been a very long time since I worked with them.

Maybe if you want an opensource engine development experience, rather than wishing for source code access that likely will never be granted, a better idea could be to search for an originally open source engine isntead. If you want C#, Stride (formerl xenko, I believe) still exists. You can grab it, contribute to it, use it. Instead of waiting and hoping.

 

In an ideal world, what you say makes sense. But we're also experiencing months of wait time for serious bugs. Some go unaddressed for years. And it seems like response times are only increasing with every year as the engine continues to grow and doesn't cut off the old fat.

I think some of us have simply lost faith in Unity ever getting this right, hence appeal for source access. But yeah, it's unlikely to ever happen. Especially at this stage of the engine's existence. There's no profit for management in this, not the kind they're looking for. And organizing and documenting a contributing process would be a gargantuan task, if that is even possible in the first place.

 

It's not similar. Unity built whole engine for me, like build pipeline, asset database, game object system, where I want to just change one part of it.

If you want to do an analogy, it's like buying a car and then changing part of it you didn't like.

While I agree that thread is kinda pointless, your arguments against source access make even less sense to me. It will never, ever, in the world will be faster to wait on a bug report than just go and tweak something yourself.
Especially since tweaking something might mean tweaking your code, to find a workaround faster just having a source code access is always better

You can't cover everything in docs, but source access is everything there is by definition. There are lots of times when I use visual studio decompiler just to make sure I understand part of program correctly, cuz its faster than going and finding docs. Always will be, because again, it is one click away!

 

The whole having source access so you can see how it works.. Doesn't really work that way in game engines. You want to learn how physics/navigation/rendering generally work that's just a horrible approach and nobody does that really.

Because game engines are just so complex and so much is not about how core things work. It's about where in the engine is their implementation buried, and a whole lot of how it's connected to other parts of the engine, etc..

So source is useful when you have an actual problem to solve that can only be solved with the source.

And the proof is that is how developers actually use UE. Good luck getting answers about how internals in the engine work, because the few people that have needed to do that, aren't hanging around the UE community. There is no sharing of that level of information to any useful extent in public UE communities. The pat answer to that type of question is 'you have source access go look for yourself'.

C++ source is just nothing like C# in terms of navigating it. And UE specifically is a forest of C++ templates. And again games engines are really far more complex then most codebases.

The example of seeing what is inside an actor is trivial to say the least. For real problems it's more like at least half a dozen levels of indirection, and you might not even know where the correct starting point is. And all the templates, my god all the templates...


Really one of the biggest advantages to UE is that source provides more stability. You can fix bugs if needed. You can preview the changes made in the smaller updates, and fix bugs there if needed also. With Unity they often roll out minor updates that break something. And then it takes them over a year to fix. This is a huge deal on production games.

Engine access for feature level changes/additions, not really as big of a deal. Actually in a lot of cases it's just easier to roll your own. Something you can do in Unity as well.

 

I keep hearing about all these show stopping bugs but have not seen anyone on these threads giving a real world example of the show stopper with no workaround, absolutely vital to gameplay and could be solved by THEM using the source code. Any takers?

 

Develop a workaround or switch to a different product. If you're expecting the engine to sink, start preparing your codebase and assets for migration to a new underlying platform. It is business as usual. Tools come and go.

If you file a bug report, AND it catches opinion of the right developer, your problem can be fixed in minutes. The thing is, this requires a specific way of handling reports which allows developers to submit hotfixes quickly or submitting personalized hotfixes to individual users.

But it absolutely is possible to have faster response to bug report instead of fixing it yourself, especially with unfamiliar codebase. Because with an unfamiliar codebase, you can flounder around for days, and then it might be easier to roll your own bypass instead.

And that is actually wrong. The point of the docs (for a product like unity) is that they're describing a contract between developer and you, which says "by my royal decree, this shalt work this way forever". And whatever is under the hood is not part of such contract. And as a result when you rely on decompiled code, you're planting a landmine into your own codebase, because ALL of t his is subject to change, and therefore you're relying on undocumented behavior.

Basically, you need certainty about which parts of the code are going to stay, and which are subject to change, and with source code access you do not have that. I also explained the situation before with unreal - you dive into code, figure out how it works, use knowledge from the code dive to make your own thing, and the next MINOR release your code breaks, because they axed the very thing you were using.

In C++, there's a nice concept : "undefined behavior".

For example, you can take a reference to null.

Code (csharp):

1.  
2. int& i = *((int*)NULL);
3.  

Or we have this nice thing:

Code (csharp):

1.  
2. i = ++i + ++i;
3.  

What would be result of such program? UNKNOWN. Because we have C++ language standard, which describes what is allowed, and those examples do not fall under that category, so it is unknown what will happen, and it is not guaranteed to have the sam result across different compilers.

Your code decompilation is like that. You check what things do NOW.

So you do not learn "how it works", but you learn how it works in the version you're using right now. And in the version the engine updates to tomorrow it can stop working.

You should not need source code.
You should not need to attempt to fix bugs for unity for free.

Those are not your job, as you're a customer. And as a customer you can switch to a different tool when the current one no longer meets your needs. Tools come and go, like I said. You might like your favorite hammer, but there's no point in getting too attached to it.

 

No different than creating a workaround in your game code and Unity making that workaround obsolete in the next update.
Seriously? That's your argument? That game engine programming is hard and Unity can update the engine and that's why it shouldn't be given for free? Lmao

 

Right, I suddenly felt really weird about reading that argument. Then I realized that Unity have been doing that all the times. Even the feature or API that was exist for so long become deprecated or even broken in next version of unity. There used to be IMGUI then there is UnityUI and now we have UI Toolkit. Each of them are not ever compatible with each other at all

 

By their logic we shouldn’t even write scripts as Unity can break them at any time with an update lol

 

lol..haha.. That is not what was relayed..lol..haha. Yer so funny lol..haha. Great argument there lol..haha.

f yer gonna argue with adults ya oughta put your big boy pants on. That lol stuff may cut it in COD chat but around here you come off as a snarky teenager.

 

That is your counter argument? Compress his argument into meaningless babble and then diss on it? Tell us about that show stopping bug stopping you from releasing your awesome game and how if YOU had access to source code you could stop it in is tracks. <taps foot waiting forever>. Too much theoretical BS from the gimme it free crowd and not ANY on the ground real world scenarios proofing their arguments. These same types will ask how to obscure their game code so nobody can rip off their framework or assets.

 

*In this version of the engine. Breaking changes between versions will exist anyway. The only difference is that you'll get notified about it by deprecation of old methods or something like this.

It's not nice, it anoys a lot of people and there's a movement to reduce amount of UB in C++ because compiler teams rely on them to make your program run a weird way. I mean sure its useful, like zero pointer, because on some devices you can actually write there. On the other hand, '++i' example looks like someone just decided to not bother with operator ordering when designing language.

Which is something you need to do for both source change or a "workaround", which you describe as "better", even though both may only work on one version of the engine.

I'm very sorry that you had that **one** unpleasant experience with UE, but it doesn't nullify all the smaller use cases people might have. Or those who just willing to not update the engine until project is completed.
Sure all of ideas you mention would help, but really none of them replace the need for the source code. It's just another option you might take if you feel like you really need to.

Unity's NavMeshAgent is garbage. It can't turn tight corners, you can't make it do it even with rotation speed that is insanely high. You can write your own NavMeshAgent, but then there is a problem, if you use NavMesh.CalculculatePath you are only getting Vector3 positions on path, if you use NavMeshQuery, you'll only get polygon types. So you're gonna have a problem, that you have no way to know whether your chracter is going towards navmeshlink or not. I can imagine it is not hard to understand why this is a big problem right?

Now I can sure make my own pathfinding. Nice. Or I can just go to source code and make it spit out what NavMeshLink am I traversing. For that one game, that I make on LTS version of the engine, that I won't update until game is released.

Another example. I want to save tons of man hours by adding motion matching to animator, so I won't need to program animations so much. Well here your story kinda ends because you can't add a custom node to animator, no way. So I need to write a custom animation system now? Why? Ever since MM was introduced it was just "a node" in animation graph that can replace part of it, not all of it, (like nonsense kinematica did) making transition very easy

I want scalable terrain solution for my game that has one splat map and one pass, but any amount of materials. But it isn't that easy to do without bindless resources, which you do not have in unity, so you might want to use TextureArrays, well then have a nice day with doubled memory requirements (Original texture + copy in array)!

You can surely shake all of these off as unimportant enough. But problem is, its up to developers to decide what is important to their game and what is not, including how far they are willing to go to achieve certain results

 

So..don't use NavMesh and write a waypoints patrol system. Problem solved. If I don't find solutions I don't eat. I wouldn't need source code, my system would be more performant than NavMesh and I would be able to customize it to meet any requirements passed to my desk.

The terrain thing is NOT A BUG. That i just a wishlist type thingee. Access to source code would not put this in your lap.

 

That's kind of what I did. I just cached all navmesh links by position into dictionary. But this solution is kinda sketchy and would be much better if done "natively"

None of what I mentioned is a "bug", but it is a feature I want to have in my game. And I don't appreciate how you ignored last sentence, where I specifically said that each game has a wishlist that it is not your business to tell me which features from my wishlist are important and which are not.

Point is all of those above would be easier to do with source access than without it, which is what I'm trying to prove. Not that I can't live without it, not that unity has to give it to me. These are reasons as to why having source access is better than not, nothing more, nothing less

 

Any more insightful comments or are you going to act like a 13 year old?

 

It is different, because workaround can bypass the whole system that is causing the problem. Meaning it will stay functional forever. A source hack relies on inner state and undocumented functionality.

This is not discord, and people here aren't teens trying to prove to the world that they're important. So "I can't believe that' you seriously think this way, hahaha yer stupid lmao rofl kek" is not gonna work as an argument.

Relying on undocumented functionality is bad as it adds a point where your code is going to break in the future. You're increasing techncial debt and are making codebase unstable and more likely to break. That's not a good thing and thus should be avoided.

It is not one. That's common pattern with UE in general. Anything you touch deep under the hood - it is gonna work like that. For example, one amazing headscratcher was "why does engine crash when you generate landscape from C++ code but only sometimes". Also, Unreal community is very unhelpful in those situations, so you'll be on your own.

By the way, t rying to generate blueprints from C++ is fun. They'll be non-functional unless you want to open editor for each blueprint (good luck if you want to generate thousands). Our local Unreal prophet has been also extremely unhelpful with trivial things like making an AssetPostprocessor replacement.

Source code in those situations is not helpful, as you'll be dealing with a Leviathan, furrowing through its guts with an icepick.

Source code access in this case only compensates for extremely poor documentation and bad design decisions. Having better docs - on unity level, by the way - would be of much more help.

And that's why I say requests for source are misplaced.

You don't have a need for source code. You have a need for docs, documentation, and quick response to bug reports. Like I said, there were plenty of successful proprietary software with no source code available that is extensible. 3dsmax, maya, photoshop. Tons of plugins, they're highly successful.

Then replace it. You use navmeshagent for prototyping, then when it no longer meets your needs, you replace it with your own subsystem. If that never happens, you'll keep using navmeshagent.

Why not? Each system is designed for a usecase. When you go outside of the bounds of usecase, you need something else.

The problem is, there is not going to be source code access. Whatever the reason is, unity is almost never responds to this sort of queries. So instead wasting time wishing for an ideal world (a wish that will never come true), I offer you approach that lets you get things done NOW.

Getting frustrated and upset does not solve problems. If a subsystem no longer meets your needs, roll your own solution. If you roll out enough your own solution, eventually you may be able to turn that into yoru own engine or a framework. Unity's job in this case is to save you initial development time, so you don't have to write your own NavMeshAgent from the start and can delay it until it becomes strictly necessary.

 

Both things that Unity is getting worse at as time goes by btw.