koobas.hobune.stream
Does Update() count matter?
As I understand, Update() Gets picked up by reflection on initialization. Would it matter to have one big update, from which everything in game gets updated, or have 100-1000 separate Update() in different scripts. I am talking strictly from optimization and speed perspective, code management or readability is not important here.
Thanks
Using one big Update instead of many small ones is, in my opinion, a bad design decision.
You may save a few thousands ticks per frame which is meaningless. On the other hand you lose the point of components.
A class should be doing only what it is meant to do but does it all. Now you want to go for a class that will also take care of all other classes on top of its own purpose. Not only it makes debugging a pain but also it means that your classes are not highly reusable.
The point is that you should design your classes so that you can reuse them with little or no added code. Think of Unity factory components, you drag them and they run, if they would all depend on a big Update, you would always need to use that big update or add some code somewhere. This is where you are heading.
So, my advice, keep everything where it belongs and avoid this God class that is aware of all others and controls them all.
Yes you will save some ticks but you should not consider them over good code.
Thanks, i was asking because i am having problems smoothly updating list of remote players. List is populated by data received from server. The problem is that once level has loaded, it hasn't actually loaded completely and it continues allocation and some asset loading, so it brakes the Update() for all scripts including Remote users. Which basically results seeing a difference in half-one meter, which doesn't sound a lot, but it is. And that amount may and will change depending of machine power running it.
I was thinking to create one single update, which loops through all remote players and updates their movement activities. That would end up me solving the only "laag" problem for that single script.
Other solution would be using ping data or timers, but that's unnecessary traffic data and unparsing which I'd like to to not use.
$$anonymous$$ight not be possible but can't you keep all players waiting for all data to be sent?
$$anonymous$$eep a loading screen until all players have finished their coroutine, then you can run:
private Action UpdateDelegate = ()=>{};
private bool areReady = false;
public void SetReady(bool value)
{
// Remove Texture
areReady = true;
// UpdateDelegate = UpdatePlayer;
}
void Start(){
StartCoroutine(Load());
}
private IEnumerator Load()
{
// Loading Texture
yield return GetData();
InformServerDataTransfered();
}
void Update()
{
if(areReady == false)
return;
// UpdateDelegate();
}
InformServerDataTransfered tells the server or the host that this player is done loading, then the server or host checks if all are ready and if so, informs them all with SetReady. The loading texture is removed, the update can start running.
If you don't want to use a a boolean then use a delegate running nothing until it is set to a method when SetReady is called.
You did not mention that this was for networking in your OP. Networking has its own set of challenges. Lockstep networking is a plausible solution for dealing with different update rates on different computers.
Players join in and out dynamically, so there's really no start or end point to start synchronization. Position also isn't sent every frame, only on other client event - input. For each client i request other user list only after OnLevelWasLoaded(), which theoretically should prevent all continuing update from laag. But that's completely misleading, and still takes couple seconds to sober up. In that time player list has been already received, because i expect it to update, but unfortunately. $$anonymous$$aybe that is because i am creating that Update with everything else for the first load. I was thinking to pre-create the update on forever living GO, so it would live and update happily, without any problems. The problem is to get the physical update math to work somewhat good even with scene loads. This is why i had the idea of somewhat "god" updater for all remote players.
@Bored$$anonymous$$ormon Lockstep networking, very interesting, looks like i will have to use timers.
This isn't an answer but comments were closed.
be warned... true lockstep networking behaves VERY badly under situations of significant uneven latency. (AKA the internet)
Yes, so another challenge is to create as much seamless transactions so it would not ruin user game experience. The lockstep technique is very interesting, i will look into it! The update problem still stays, i will try separate update method on previously created global GO. Which kind of naive, but it might work, if not, separate thread might do the job.
