Design Decisions

EasyCode Opinionated Design Choices

• EasyCode uses Zenject dependency injection internally so I can scale EasyCode without breaking projects in future releases, and to be friendly/compatible with teams working on big projects that already use dependency injection. Also, I am using Project Context prefab in Resources folder. If you have a Project Context as well it may conflict with EasyCode Project Context. Zenject supports IL2CPP but be aware there may be issues if using IL2CPP read more here about IL2CPP compatibility

• The 3D demo scene uses NetCodeForGameObjects. I was originally going to use Mirror Networking, but they made a lot of breaking changes and at the time (Oct 2022) tutorials I followed/bought weren't updated, so I decided to adopt NetCode since it's part of Unity's Ecosystem and was finally production ready.

• Designed with some static variables to keep track of session (EasySession.cs), instead of Singleton design pattern, for persistent session data across scenes (I had problems properly Implementing Singleton, previous instances would be destroyed and replaced with new instances thus destroying session data. This happened back in late 2020/early 2021 when I was still a fairly new programmer. I have learned a lot since then and re-written/re-designed EasyCode about 3 1/2 times and still went with a few static variables over singleton design pattern).

• Uses Reflection for Dynamic events. It is the slower option, but I don't know how to use Mono.Cecil or C# Dynamic Methods with IL Emit/Opcodes (maybe one day).

• At the time of this writing namespace VivoxAccessToken located at Assets/EasyCodeForVivox/Plugins/VivoxAccessToken.dll is basically a direct copy of how to implement Vivox Access Token from the Vivox documentation. I didn't change method names so it would be easier to reference the docs.

VivoxAccessToken may be changed in the future since later Unity Versions since they provide a NewtonSoft Json package in the Unity Package Manager which can be used to serialize instead of the JavaScriptWebSerializer. This would mean one less Plugin/dll to maintain separately, and source code would be included in EasyCode . Once Unity releases 2022 LTS I may make the switch to support 2020 and above with a dependency on Unity's version of NewtonSoft.Json

• Designed EasyManager.cs to be inherited from. You can reference it using GetComponent<EasyManager>(); to gain access to its public methods or use Dependency Injection in your classes

• Balance of Ease of Use and Performance (My laptop is pretty performant (Processor Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2208 Mhz, 6 Core(s), 12 Logical Processor(s), 16 GB RAM, although I am running Docker on WSL so it does steal some performance) so results may vary. Only when using Dynamic events should you worry about performance. Even so events are fire and forget and you should never see a performance hit)

Designed with scaling in mind but if you think your game is going to have over 10, 000 players or need an enterprise solution I would look at Assets/EasyCodeForVivox/Scripts/VivoxBackend and EasyManager.cs And implement your own solution based on the code in this asset and Vivox documentation. Especially if you don't like my naming conventions or design 😁. I am open to feedback and pull requests to make EasyCode a goto solution for Enterprise level games/apps