It works in reverse

So my latest Unity3D “eureka!” moment that’s a “well duh” for the more experienced: Turn off components by default in the interface, then turn them on in code as needed, rather than the other way around.

I decided to grapple with Unity’s networking / multiplayer features early on, thinking myself very wise for planning ahead after witnessing so many games adding multiplayer as an afterthought. Even though Awareon is mostly a single-player game, multiplayer is best when it’s well integrated rather than tacked on.

My first go seemed easy enough. RPCs, gotcha. Network Views, that’s straightforward. Reliable and unreliable, standard stuff. Roll my own prediction code? Okay that’s involved and intriguing, so later. For now, I figured just dropping in a Network View or two would suffice to get the ball rolling.

And then the errors piled on. This component expects something from that component, but it didn’t instantiate over the network. That sort of thing. At first I fumbled around, trying to sort out what the dependencies were. Then after reading this http://answers.unity3d.com/questions/128101/instantiate-2-players-on-network-problem.html and this http://answers.unity3d.com/questions/19172/camera-and-control-problems-with-network.html

— I realized I was being stupid trying to step forwards through a problem that needed to work in reverse. It avoids a lot of unecessary problems. It may seem backwards setting it up, but It makes sense: From the engine’s perspective there’s no point putting things in, just to take them back out.

This solution is probably apt for most of what Unity calls the Game Object Component (GOC) model. Attach and configure the components conveniently within the UI, but disable them until needed.