Question

I’m programming a big game in Java and I’m trying to optimize the code but also to keep the code neat and well organized. Now I am unsure if I should use the public static field of single classes that have a couple of variables that are used by a lot of instances.

For example the class camera has an x and y position that define what part of the map the user is looking at and what needs to be drawn to the screen. Currently I’m benchmarking with 50 000 units and I have the following options to draw them.

1: Store a reference to the instance of the camera in each unit and call getX() and getY() when it should be drawn:

public void paint()   
{   
   paint(x - camera.getX(), y - camera.getY());  
}  

2: Supply the coordinates of the camera as arguments to each unit when it should be drawn:

public void paint(int cameraX, int cameraY)  
{   
   paint(x - cameraX, y - cameraY);  
}

3: Make the x and y variables of the camera class static:

public void paint()   
{   
   paint(x - Camera.x, y - Camera.y);  
}

I’m interested as what is generally seen as the best solution and if it affects performance. Perhaps there are more ways to do this I haven’t thought of yet?

Thanks!

Answer 1

I’d suggest you create a Painter class and do the following:

public void paint(Painter painter)  
{   
   painter.draw(x, y, unit_sprite);
}

That way the units don’t have to worry about the existence of a camera. It is none of the unit’s business how that works. The unit just needs to know how to draw itself on the global co-ordinate scheme and the painter will understand how that relates to the actual screen co-ordinates.

Why is this a good idea?

• Reduction of code, each unit doesn’t have to worry about translation to the correct co-ordinate frame. All of that code exists once in a single location.
• Ease of change. For example, suppose that you decide to implement a zoom feature. If each unit does its own translation that would be a pain. However, if all of that logic is in the painter, you can modify the painter to take care of rescaling the images and determining the correct offsets.
• Decreased dependencies, the units don’t know what a camera is, they are simpler because they don’t worry about it.

Regarding your proposed solutions:

1. Storing a reference to the camera on your object assumes there will only ever be one camera. What if you implement something like a split view? This may be unlikely, but by storing the reference you unnecessarily pretty much lock yourself into one perspective.
2. The problem with splitting up the variables is that logically the two pieces are one item. This makes it a bit harder to figure out what is going on, will cause problems if you someday need more parameters, and also gives information to the unit which it really doesn’t need.
3. This suffers from the same problems of #1, it locks you into a single camera being used all over the place. The unit shouldn’t be responsible for defining how the camera is used.

Regarding performance:

The difference is going to be almost nothing. I’m not sure what method will win in a performance battle, but I can tell you if you have performance issues they are going to be somewhere else (I’d guess in actually blitting functions). By combining all the code relating the offsets is a single location, my proposed method will make it easier to implement an optimization. For example, a common optimization is not draw things which are offscreen. If you have 20 functions all calculating offsets and invoking drawing functions, you’ll have to go to each of those function and change them. If you use a painter, then you can simply change the painter class to ignore request to draw outside of the visible area and you are done.

Regarding static variables in general:

I consider static variables (and singletons) to be global variables and thus virtually never use them. Making them static ties me to particular decisions. I’m not smart enough to make all the right decisions up-front and so I need my code to be flexible.

Some Guidelines:

1. If you find yourself needing to access the data inside an object, i.e. the x,y value consider whether you should instead tell that object to do something be invoking a method. I.e. Tell Don’t Ask.
2. If an object (like Painter) is only used for a particular task by an object then it should be a parameter not a member variable.