Problem description:
At some point I want to take control of the player's mob to act out a (very) short cut-scene of sorts. So far I haven't had to make a single alteration to Move(), and I fear that doing any may cause more 'lag' issues than lag itself. I'm sure such effects are minute, but I'd much prefer to have none at all, considering Move() is called so often.
So, avoiding the obvious altering-Move() option, is there a way to very temporarily remove control of a mob from the client, keeping their focus on that mob (so they keep looking at it), and then returning control to the client?
OR: am I just being super paranoid with the effects on gameplay from altering Move()?
ID:1192270
Mar 9 2013, 8:49 am (Edited on Mar 9 2013, 12:44 pm)
(See the best response by Stephen001.)
|
|
I figured it'd be less processor-intensive to do nothing, but how much does an "if" cost? I don't like the idea of every single mob in the world having to run through an "if" every single time they move when there's only the slightest chance it might apply to them.
|
Move() isn't called /that/ much, as such. It's just heavily loading Move() will be the thing that makes players observe latency, as they press a key, expect a prompt response.
That kind of if statement checking a boolean value, is very inexpensive, and so probably the kind of thing you want. The trick is mostly to make sure you limit what you add to Move() to necessary cases. This is directly control related (and response to keys pressed), so .. an ideal candidate for adding to client/Move(). |
In response to Ease
|
|
1. It's not every mob, just every client.
2. You're being extremely paranoid if you're worrying about if()s, as there's nothing more you can do to make it any faster. You're very likely having lag issues somewhere else, if at all. If you don't want to see the if(), you can just use an operator. It might even be more "expensive," who knows.
client/Move() return has_control && ..()
|
You're being paranoid, I think. It's actually less processor-intensive to do nothing, by the way.