How should I implement the "Observer" pattern with respect to a game world?

Question

I'm thinking of ways to implement the Observer pattern in a game I'm developing at the moment. I can have a Game World (local map) with Game Objects (player, NPCs, monsters etc...) inside of it. Other Game classes (like quest progression tracker for flagging triggers, location tracker for path finding, or maybe a new map need to be loaded into memory and rendered to show the new area the player just walked into) need to be notified when the player walks into a building, or fires a projectile. Also the input listener needs to be aware of when the user presses a key or clicks the mouse, and somehow transport that information to the rest of the game so that it can allow the appropriate actions to take place.

So I'm stuck at the implementation stage. I know I can use the Observer pattern, and possibly the State pattern as well. I know I'll need a Game World (Subject), Game Objects (Listeners), and Game Events (triggers the Game World to render the changes). However that could be the wrong way to go about it, any suggestions?

BTW, its a 2D JRPG tiling styled game, in the fashion of Zelda, Breadth of Fire, Pokémon, or the older Final Fantasies

Alright I've gone and done an implementation, but ran into a few minor issues, although it seems to be working properly.

public interface WorldListener {
    public void OnWorldEvent(WorldEvent e);
}

Above is the Observer that listens to the subject.

public class WorldEvent {
    final int WorldObjectMovedEvent = 1;
}

Above is the Event that triggers a notification.

public class World {

    static WorldListener listener;

    static void addWorldListener(WorldListener wl) {
        listener = wl;
    }

    static void WorldChanged() {
        listener.OnWorldEvent(new WorldEvent());
    }
}

Above is the subject that only stores one subscriber at the moment, I'll make it into a list once i write a class for another observer, right now, I only have one Observer. There is no need for a list at the moment.

public void OnWorldEvent(WorldEvent e) {
    System.out.println("Something has happened in the world");
}

static private void addWorldListener(WorldListener wl) {
    World.addWorldListener(wl);
}

The code above goes into the object that is currently acting as an observer, when an event is fired, it triggers the world's WorldChanged() method, which in turn fires the OnWorldEvent of any listener.

The problem I have ran into is that I can't move the WorldEvent, WorldListener, or World classes into a separate package under the moniker World.my.game because of the static reference. So I'm not sure I'm implementing it correctly. Also if there are any suggestions on making this better, or if I'm flat out doing it wrong let me know, as I haven't delved into design patterns yet and this is my first attempt.

Answer 1

The problems i have run into is i can't move the WorldEvent,WorldListener, or World classes into a separate package under the moniker World.my.game because of the static reference.

Don't make the listener inside the World object static. A static class member means the object is shared across all instances of the type (all instances of World in this case). That's not want you want here: you want each World to have it's own listener, so client code can listen to the individual world or worlds it cares about.

i haven't delved into design patterns yet and this is my first attempt

This is a problem that most people have when first hearing about or approaching "design patterns." Design patterns exist to create a common vocabulary for talking about problems and solutions. They should not be viewed as solutions in and of themselves. That means when you encounter a problem, you shouldn't necessarily go hunting for a "design pattern" to try and fit over the problem, and you shouldn't worry about implementing the solution to a problem "correctly" in terms of the canonical definition of the pattern.

Focus instead on solving the actual problem. In this case, the problem you have encountered is that you need some way for other code to react to world events when they happen. And it's true that this the basic premise of the observer pattern -- but that doesn't mean there is a single "correct" way to implement the observer (and there shouldn't be!), nor does it mean you should think about the solution in terms of the pattern. It is a subtle distinction, but it will help you avoid "square peg, round hole" problems in the future if you focus more on the needs of the solution rather than the definition of the pattern.