Hmm, I would keep the method comments. That is important, especially for public ones.
Here is how I would comment the function (in c++ that is)
/*
* Calculates the number of Tiles from a reference point to the origin of the Area of Effect
* param otherPoint The reference point.
* throws InvalidPointException when otherPoint does not meet requirements
* return: The distance from the reference point to the origin of the Area of Effect
*/
public int distanceFromCenter(Point otherPoint)
And as mentioned use a Point class for x,y pairs.
You should also be throwing exceptions on invalid parameters.
Might also mention whether it should round up or down, or choose the closest integer on the return.
Also I would tend not to use uncommon acronyms in my code, i.e AOE, if you want others to read it.
In C++ I would probably use a helper function to determine if a point is in an Area of Effect. But that would be hard for Java.
E.g bool isInAreaOfEffect(AreaOfEffect area, Point reference);
Because I dont believe it is the AreaOfEffect class's job to determine that. (But that is just me)
As mentioned use separate classes for each AOE type, as there will be much difference between calculations.
My thoughts on variable naming.
Member variables should start with a 'm' and use Camel case for names, e.g , mIntSize
(You could append argument variables with 'a' and scoped variables with 'v', but that might be going too far.
Also I would drop the variable type labeling. Nearly everyone working with code uses a modern IDE that will tell you what the variable type is. Find a modern style guide that was not written by a teacher
Also some of you variables are poorly named. E.g anything starting with an 'i' that is not an index variable in a loop is bad. (I get it is 'i' for int)
int ix2 = 0; //The length of the line for ix
As soon as I saw this code I though, ok ix2 is a loop variable but what is ix1? This should be named lineLengthOfX or lineLength_x or whatever.