Java Classes in game programming?

I'm doing a little strategy game to help me learn Java in a fun way. The thing is I visioned the units as objects that would self draw on the game map (using images and buffering) and would react to the mouse actions with listeners attached to them.

Now, based on some tutorials I've been reading regarding basic game programming, all seems to be drawn in the Graphics method of my Map class. If a new unit emerges, i just update the Map.Graphics method, it's not as easy as making a new Unit object whi开发者_JS百科ch would self draw... In this case, I'd be stuck with a whole bunch of Map methods instead of using classes for rendering new things.

So my question is, is it possible to use classes for rendering units, interface objects, etc, or i'll have to create methods and just do some kind of structural programming instead of object oriented? I'm a little bit confused and I'd like to have a mental blueprint of how things would be organized.

Thanks!

Sounds like your objects need to have a common interface that they can all be down-casted to for rendering.

E.g. have a generic list of your interface type, populate it with the game objects, then enumerate the list and call the common method to do the rendering.

This is C# code, but it should be similar for Java

public interface IRenderable
{
    void RenderMe(Graphics graphics)
}

List<IRenderable> myGameObjects;

foreach (IRenderable myGameObject in myGameObjects)
{
    myGameObject.RenderMe(myMap);
}

While the objects are held in the list they can respond to events and update their internal state ready for the next render cycle.

As ck said, you could do this with a drawable interface, something like:

public interface GameElement {
    public void draw(Graphics g);
}

public class Sprite implements GameElement{
    private Image image;
    private int x;
    private int y;
    public void draw(Graphics g) {
                g.drawImage(image,x,y,null);
    }
}

public class GameLoop {

        public void drawElements(final Graphics2D g, final List<GameElement> elements) {
                for (final GameElement gameElement : elements) {
                        gameElement.draw(g);
                }
        }


}

but the way you said you want to do it, with a listener, may give you problems in the future. As dash-tom-bang already pointed, all elements are rendered in a single game loop, after all of them were already updated. If you do this with a listener and you have a game loop or any other thread modifying the unit list, you can end up with a concurrent access modification. Besides, this way you will draw all elements in a single point, that will avoid some weird flickering on your game.

While "real" game projects come in many forms, ultimately you have something like this:

while True:
   ProcessUserInput()

   for o in objects:
      o.Update()

   for o in objects:
      o.Render()

Use whatever mechanism you find dear to implement any and all of these functions. :) Polymorphism is fine, so you should feel free to use that if you're comfortable with that. The "world map" likely should be the first item in the list, unless your rendering system is sufficiently advanced to handle out-of-order drawing (depth sorting, basically).

From your question, it may be that the units are owned by the map? In that case, the Map.Render function would iterate over all of the units that it owns, calling Render on each one of them in turn. Regardless, it's probably cleanest if the code to draw a unit is in the class for that unit.

Good luck!