client.eye in Design Philosophy

ID:152496
 
Aug 4 2006, 1:25 pm
Well, I recently started working on an action game, and I figured it would work better of the eye was offset to the front of the char a bit, to make it easier to sneak up behind someone, as it should be.

The method I used was to make an invisible dummy mob that constantly stays X feet in front of the main character, which is the concentration of client.eye. I just came across byond://Yota.OffsetEye , and I wanted to get some opinions as to which method is more efficient, and would cause less lag. Is it harmful to use a dummy mob to guide the eye around?

The advantages I've noticed to my design so far (haven't tinkered with Yotas much yet) is that there's no problem with the eye trying to escape the map, since the invisible mob can't go that far anyway, and the movement of the eye is more fluid.

So, opinions anyone? I want to know if I should redo how I'm handling the eye or not.
#1 Aug 4 2006, 1:29 pm
I use a modified version of Yota's OffsetEye in Faction Wars. I don't have any problems with it... except for the fact that it's missing a get_steps(), but that's not too hard to code yourself.
#2 Aug 5 2006, 11:15 am
Mathematically setting the eye is likely to be much more efficient because there isn't any overhead involved with moving both the "actor" mob and its "eyesight" mob simultaneously. However, efficiency is relative: I can't imagine either method would produce any noticeable CPU hit.

I would say that the "eyesight"-based version would actually produce less lag, however, because the server wouldn't be transmitting "update client.eye" messages to the user, just positional updates of the eyeball (one presumes that after all this time, BYOND is streamlined most for the server telling the client where objects have moved).

You might be better to use a /obj instead of a /mob for your eyeball: /objs use smaller memory footprints. client.eye can be attached to a /obj just like it can be attached to a /mob, and /objs have all of the mobile features of mobs but none of the extra baggage that comes from having to store the client key and client data object.