Update Everywhere or Not?

So I’ve recently taken over a project that someone started coding YEARS ago. It’s a multiplayer project. The way it was originally done was that each player’s client has a GameManager object. And that GameObject had a script attached to it that had the well known MonoBehavior Update() method. Inside that Update every other local object had their own custom OnUpdate method called.

My question is…is there any inherent/default benefit from doing it that way, instead of just having every object that needs to be tied to Update() be a MonoBehavior and call Update itself?

 

When I see that done I assume that there was a reason, such as "we must make sure all of X has been updated before Y gets updated." This may or may not be the case in your code. You could attempt to reason about if it is true or not, but such order-of-execution dependencies can be very subtle to truly prove to yourself, especially if it is a multiplayer project, and especially if it is someone else's code.

For instance I was making a little vehicle-scroll-on-2D terrain game and realized that half the time at high speed the vehicle didn't track the generated terrain. Turns out it was a 50/50 chance whether terrain got moved or vehicle got positioned first each frame, so I made a master manager that first moves the terrain, then emplaces the vehicle, and my floaty vehicle was instantly fixed.

 

I thought the same thing and after some extensive testing there was only one area where this was true and I’ve already done away with that portion.

So other than the concept that you mentioned above, there nothing that it offers in terms of optimization and/or performance. Either way is essentially the same thing?

 

I'd be very skeptical of any claim that one way was significantly faster. There may be a profiler-measurable difference, but I'm going to guess it would be trivial, and likely to vary from platform to platform and use case to use case.

In light of that I would say "Do whatever feels bestest to you!" I mean you gotta maintain it, and that's where the true costs are. There's probably lots of other stuff to optimize first!

For objecty-orienty- maintenance I suppose you could make an

IUpdateable

interface and have those objects implement it, but eh, that seems like a lot of extra typing for almost zero obvious benefit.

 

I seem to recall a talk, where they said, that having 10000 object updated by one object vs 10000 objects updating themselves is way better for performance, but that might've been saying, that that script will do what the update method would've done, so for example it would move the objects instead of calling update on them.

Found it:
https://blog.unity.com/technology/1k-update-calls
It's actually about this exact pattern