There was a short discussion about Unity source access [in this thread (link to the first post in the conversation)]( Unity Future .NET Development Status page-28#post-8643051), 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).
bool AActor::smile:estroy(bool bNetForce, bool bShouldModifyLevel)
{
// It's already pending kill or in DestroyActor(), no need to beat the corpse
if (!IsPendingKillPending())
{
UWorld* World = GetWorld();
if (World)
{
World->DestroyActor( this, bNetForce, bShouldModifyLevel );
}
else
{
UE_LOG(LogSpawn, Warning, TEXT("Destroying %s, which doesn't have a valid world pointer"), *GetPathName());
}
}
return IsPendingKillPending();
}
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.
