Home > Assignments > The Lone Visitor

The Lone Visitor

The Visitor Pattern has some serious power. It’s just begging to be tossed into a data structure. Unfortunately, I don’t have much of any data structures going on other than some ArrayLists. But, powerful none the less.

I decided to use the Visitor Pattern for drawing my game entities to the screen. So, I created a Visitor interface declaring some visit() methods for all the entities in my game (Ship and Projectile). Then, I made a concrete class called Draw2DVisitor, which, as you may guess, draws things in 2D.

Prior to implementing this Visitor, the Ships and Projectiles had the capability to draw themselves. Although this works and is a common method, you’re stuck with graphics. What if for debugging purposes you wanted to skip graphics and instead print to the screen all the information about where your entities are located? Well if you provided an interface for all kinds of Visitors to use, you could simply create a PrintStringVisitor that printed this information to the screen. Amazing.

So after removing the draw capabilities from all entities and creating the Draw2DVisitor class, I implemented the Visitor into the game. Unfortunately, I quickly ran into a minor but annoying problem. Due to the design of my game loop, the graphics for the window are instantiated every iteration of the game loop, which means I have to provide this new graphics setting to the Draw2DVisitor so it knew where to draw the entities. Well, the only way the Visitor gets this information is through its constructor, which meant I had to declare a variable for the Visitor outside of the game loop, and instantiate a new Draw2DVisitor every iteration of the game loop, providing it the newly created graphics setting. This bothered me. I don’t need to be creating a new Visitor every iteration of the game loop, that’s a lot of unnecessary object creation! But I couldn’t see any way around it due to the already implemented graphics.

Singleton saves the day! Wait a minute. I don’t need any more than one Draw2DVisitor anyways since the single instance is passed around to every entity, why not make it a Singleton and restrict instantiation? Well, it turned out to fit nicely. I changed the Draw2DVisitor class to a Singleton, and provided a static method to retrieve the single instance of the Draw2DVisitor. Since the Draw2DVisitor needs a Graphics2D setting to draw to, I simply added this as a parameter into the static retrieve method. Now when the retrieve method is called, it sets its internal Graphics2D variable to the given parameter, and returns the single instance of the Draw2DVisitor.

Now, each iteration through the game loop, rather than instantiating a new Draw2DVisitor, a simple method is called to retrieve the single Draw2DVisitor and set the appropriate Graphics2D. Job well done Singleton.

Advertisements
Categories: Assignments Tags: ,
  1. danielmundra
    February 29, 2008 at 9:23 pm

    Dear Nate,
    Awesome project. Well done. I am going to recommend you to Kent for presentation in dead week.
    Cheers
    Daniel Mundra

  2. Michael
    April 21, 2008 at 8:34 am

    Umm… Singleton is rarely a good or even valid answer unless your obsessed with non-OOP programming, in which case I hope your in C and then there is really no need for it anyways 🙂 You should check the gamedev forums a lot of highly intelligent people came up with a few billion reasons why a singleton is wrong (unless you have a physical hardware limitation limiting you to only one instance) in nearly all situations people use it in.

    I’m not really sure why your Draw2DVisitor needs to be accessed by the sound system anyways *shrug*. Proper design makes the singleton useless in this fashion anyways. You can never truly say that in a year from now you won’t come up with a reason why a second Draw2DVistor wouldnt be needed, then with a singleton you’d have to refactor ALL Your code. If you think you just need one (say like a logger) then just make one.

  3. a1979shakedown
    October 25, 2008 at 7:36 pm

    You’re right Micheal, and I’m fully aware of the pros and cons of the Singleton pattern. But, my class that this project was for was all about design patterns, so in that context, implementing the Singleton pattern to solve a problem was exactly the right thing to do.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: