How I Used Design Patterns in Arcane Lands (Part III)

Observer Pattern

To implement loot bags, I used the Observer Pattern to establish a one-to-many relationship of a single loot bag, to many players. With multiplayer in mind, this implementation of loot bags using the Observer Pattern becomes essential.

The system for loot bags, as well as other inventories with multiple views, is as follows:

A single subject has the true source of data regarding the inventory items. In this case, a loot bag will have an inventory (ItemRow) containing an array of ISlots, which each have a single Item. Meanwhile, each player who “views” the loot bag will see only a display of the main loot bag. This means that the display of the player should always reflect the state of the loot bag subject, rather than making a copy of it and possible making changes that are not viewed by other players.

Below is an image depicting the relationship between the LootBag subject and the PlayerInventory observer.

Notice that PlayerInventory.Swap() will call the owner of the ISlot to perform the Place / Remove actions.

Because of this, when a player calls Swap() on its own ISlot in its LootBag view, GetOwner() will return the original loot bag, which will then call the Remove() or Place() function on all observers.

One may note that this may lead to infinite recursion, as the player’s ISlot will always return the subject LootBag in GetOwner(). This is solved by temporarily detaching the subject LootBag as the owner, setting the player’s view as the owner, calling the Remove() / Place() function, then setting the subject LootBag as the owner again after the function is complete.

This method of calling the function in the subject and only in the subject is important for multiplayer. This is because of synchronization issues. Within the subject, a mutex lock can be applied to ensure that only one Place()/Remove() can be run at a time and the integrity of the items are maintained. In other words, the danger of item duplication can be addressed while allowing multiple players to view the loot bag.

An important feature to note is that using the observer pattern, the game system can allow loot bags to exist without a display. This means that a loot bag can be created before it is observed by any player and exist for some time even after all players have detached from it.

Other Notes:

Originally, I have designed a similar system in my other game, Alchemy Tavern, where the internal data structure of inventories are detached from various displays. For example, the market, the beaker, and the player all have the same inventory structure, but their displays are varied. I realized this pattern of calling the mutative functions only in the subject, and letting the subject forward its changes to observers by drawing the entities, drawing sequence patterns, and eventually finding that this is the most sensible way to handle the data.

In fact, this discovery was the instance that made me deeply interested in Design Patterns. At that time, I did not know what such pattern was called. I only understood that it made sense to handle inventories and displays in that manner. Eventually, I picked up the book Design Patterns by Erich Gamma, et al. and learned about these patterns much more clearly.