Convert to Unity Package Manager (UPM) package

[frarees]

This draft illustrates how the repository could become a package compatible with Unity Package Manager.

This branch can be directly fed into Unity (more details on the Unity docs):

https://github.com/frarees/DarkRift.git#upm

Additionally, UPM packages can be:

• Packed and distributed (.tgz files added as releases in GitHub) using npm pack.
• Uploaded to an npm registry such as OpenUPM (see Scoped Registries).

The current repository folder structure is not the only way to set up UPM package support. This structure favours ease of use and maintainability when UPM is the main distribution mechanism and Unity the main target.

This proposal makes DarkRift accessible for Unity developers across desktop platforms to contribute and navigate through DarkRift's code:

• No dependency on Visual Studio — tests have been rewritten to use UTF / NUnit. Makes life easier for Linux and macOS users.
• Code directly available from within Unity.
• Simplified development pipeline — don't have to develop and build outside of Unity.

Other benefits:

• Potential to write Play Mode and Edit Mode tests.
• Ability to include samples as part of the package.
• Seamless installation— this isn't just unpacking a compressed file into your Unity project, as it's the case with .unitypackage files. Unity handles package installation, removal and upgrading through the package manager window and APIs.
• No clutter as part of end-users projects — files are not dropped in Assets/, but in Packages/ in read-only mode (unless you install the package for development, in which case you can modify it. Which is the intended setup for contributors).
• Using Assembly Definitions — code is compiled to different dlls with different build parameters. End-users can also use asmdefs to define client/server logic within the same Unity project. Example based on the agar.io tutorial:

Note how client, server and common assemblies are defined in the same Unity project. The server DLL is discovered by the XmlUnityServer without additional actions (compiled assemblies are located under Library/ScriptAssemblies).

Downsides:

• No mocking support — Unity doesn't offer mocking as part of UTF out of the box. I didn't feel bundling Moq as part of DarkRift was worth either.
• Unity-centric setup. Compatibility with other engines is completely possible, but not as ergonomic to develop or build by default.
• The build artifact is no longer a set of DLLs, but a package with the source code. Creating DLLs is still possible as an additional build artifact.

TODOs:

• Not all tests are ported over.
• Console project not included.
• Sample content.

Feel free to list additional items I might have missed.

Note that Unity is planning to support first-class support for csproj files. Assembly Definitions will convert into csproj files and those will be consumed by Unity directly.

[4real]

Thanks for the contribution. At this stage, I am basically going to copy your .asmdef/package definitions as a stage 1 to permit installing DR2 from the UPM. I need to discuss with @JamJar00 if it makes sense to port tests to Unity, and to what degree. DR2 is not really Unity specific.

[4real]

After porting this to a subset of the changes as described in my previous message, I'm unsure of "autoReferenced": false (having been absent from Unity for a few years when UPM happened). Is this going to require everybody to add references even if they don't have .asmdefs?

Empirically, I have a basically empty project, where I can't find any DarkRift types from my new script unless I turn autoReferenced to true. But maybe I messed something up in how I did this. I will link in my other PR.

I guess it would be weird if "autoReferenced": false is that limited (yet necessary to reduce compile times), so maybe there's a proper way of dealing with this that I'm not aware of.

[frarees]

Is this going to require everybody to add references even if they don't have .asmdefs?

Yes. When there's no auto-referencing, it forces users to declare explicitly they want to use the assembly, forcing users to create and organize their their client/server assemblies through asmdefs, as shown in the screenshots above. Which albeit requires setup on the users side (creating one folder per assembly + an asmdef in there), helps maintain common+client+server assemblies in the same project and define how they reference each other and when/if they should be included in the compilation.

If you don't want users having to define their asmdefs, here's other ideas that come to mind:

• Auto-referencing. With this, both DR client and server are always part of the Unity build, but users can work without having to use asmdefs themselves.
• Auto-referencing + have users define a constant (e.g., INCLUDE_DARKRIFT_SERVER) for the server part to be included.
• Auto-referencing + split in two packages: DR client and DR server. Users decide if they want both or just the client bits. Dependencies between them can be defined, and within Unity you can get a defined constant when it's imported e.g., HAS_DARKRIFT_SERVER.

However, on none of these scenarios it's easy to keep your network-related codebase in Unity, since everything will live in the same assembly (Assembly-CSharp). (On most scenarios) users would still have to maintain server (and common?) outside Unity.