Forums » Impact Engine » Encapsulation of distanceTo, angleTo

It would be nice if the distanceTo and angleTo Methods would be separated into two methods.

One that calculates the distance/angle with any given x and y positions.
And one which takes another entity just like the current methods (and utilizes the x,y-version of the methods). That would be a bit nicer than duplicating code to achieve e.g. movement towards a given point (mouse). Using a pseudo-entity with pos and size members is possible atm, but thats not so nice either.

Quote from wicht
It would be nice if the distanceTo and angleTo Methods would be separated into two methods.

How are they not separated currently?

myEntity.distanceTo(entityA);
myEntity.angleTo(entityB);

For what it's worth, when I'm doing a lot of mouse interaction I've also found that having an invisible entity that follows the mouse position is really useful.

For example, rather than do all sorts of calculations to determine if the mouse is over an entity, I simply use the collision detection of my invisible EntityMouse object to let me know when I'm over it.

And I don't consider it a psuedo-entity. It's a full Entity just like any NPCs, triggers, elevators, or main player.

We're not talking about the same thing i suppose ;)

With separated i meant:

myEntity.distanceTo(entity);
myEntity.distanceToPosition(x, y);

same for the angleTo method.

For what it's worth:
Atm, if you want to use this methods, you need either an invisible entity or an entity-like object (which at least has the .pos and .size attributes).

Both is definitely possible, but it's more like a workaround that would not be necessary if:
a) you duplicate the calculation-code of distanceTo/angleTo (duplication of code > bad)
b) encapsulate further (splitting as mentioned above)

Why not use invisible entities: Because it may double the entities needed, depending on gameplay. For example if you have a fairly free world, on which PCs and NPCs move, all of them may move idependently from other entities (especially if they are controlled by a socketserver (e.g. other remote players) or something other generic).

It's also quite easy to integrate without changing the api in a destructive way. Sure, i can overwrite the protoype, but i think it's a quite good feature, especially if you use mouse or automatic controls for entities.

Ex.:

angleTo: function(other) {
    return this.angleToPos(other.pos.x + other.size.x / 2, other.pos.y + other.size.y / 2);
},
angleToPos: function(x, y) {
    return // calculation stuff with direct positions
}

As said, it just would be cleaner to have that. You won't need it to survive, you can work around everything ;)

EDIT: Shame on me, encapsulation is not the correct notion ... it was a hard week ;) but i hope i made clear what i meant.

Yeah, not a huge deal, but methods for getting distance and angle to an arbitrary point would be cool. For now, i'm just defining my own.

I use these two in my base object class that is a subclass of entity that all of my game entities derive from:

angleToPos: function( pos ) {
return Math.atan2(
pos.y - (this.pos.y + this.size.y/2),
pos.x - (this.pos.x + this.size.x/2)
);
},
distanceToPos: function( pos ) {
var xd = (this.pos.x + this.size.x/2) - pos.x;
var yd = (this.pos.y + this.size.y/2) - pos.y;
return Math.sqrt( xd*xd + yd*yd );
},