Multiplayer woes

One of the downsides of Unity as a tool is the amount of experimentation and churn they put into some of their core features. Proper dynamic SVG integration was a minor one that has been benched, multiplayer is a major feature that they have taken a long time to get right.

I originally developed a marching cubes version of Soul Invictus and dabbled in one of the earlier iterations of Unity’s multiplayer, UNet. It was fairly buggy and tough to get to grips with but a lot of the features were similar to what you get with their latest offering: Netcode for GameObjects. They had a transition period where they kept discouraging new development from their original system but had not yet properly released their new system, which for a solo indie dev where development time is of utmost value, gambling on either option seemed quite risky.

So for a time I went with Mirror, a third party plugin that used UNet as a basis and fixed a load of bugs. It was easy to adapt and largely easy to transition from, but I felt I was spending a lot of time debugging and was struggling with its use of a separate compiler called Weaver for its Netcode. It felt like Unity would say something is ok, only for Weaver to overrule it and have a compile time error after the fact. As Unity can, on its own, get itself into a tizz with compiler warnings, assembly definitions, project files and breakpoints at times, eventually the pain felt like it was outweighing the benefit, when I knew a Unity official plugin was in the offing.

Luckily the new system seems very similar to the old UNet and Mirror, and appears to be decidedly less buggy. There is some issues with parenting network objects that are a pain, and some of the options around serialization need significant workarounds, but I think I have made some good progress with it, and expect to use it in the final release of Soul Invictus.