Modeling the World with Prototypes

Let’s say we’re writing a dungeon-crawl-style game in the vein of Nethack. So along with the  rooms and items that we’d expect to find in a text adventure game, there are also various semi-randomly-generated monsters who periodically confront the hero. Different types of monster have different stats, such as health, speed, and strength. They each have their own types of attack as well. We’d also like to be able to load up the list of monster types at run-time, from a user-editable file like this:

gnome:
  attack_text: hits you with a club!
  max_hit_points: 8
  strength: 5
  speed: 9
troll:
  attack_text: attacks you with a pickaxe!
  max_hit_points: 12
  strength: 10
  speed: 5
rabbit:
  attack_text: bites you with sharp, pointy teeth!
  max_hit_points: 50
  strength: 50
  speed: 50

One way to model different monster types would be like this:

class Monster
  attr_reader :health
  def initialize
    @health = max_hit_points
  end
end

class Gnome < Monster
  def name
    "gnome"
  end

  def attack_text
    "attacks you with a pickaxe"
  end

  def max_hit_points
    8
  end

  def strength
    5
  end

  def speed
    9
  end
end

g = Gnome.new
# => #<Gnome:0x00000004020130 @health=8>

Here there is a Monster base class, and a subclass for each type of monster. But this doesn’t really lend itself to dynamically loading arbitrary monster types from a file, so we look for other approaches.

We experiment with one design that uses MonsterDefinition classes to hold the static attributes of different monsters. A MonsterDefinition can be told to #spawn a Monster instance. The Monster instance has a reference back to its definition, as well as an instance-specific health meter (initialized based on the max_hit_points of the MonsterDefinition).

class MonsterDefinition
  attr_accessor :name,
                :attack_text,
                :max_hit_points,
                :strength,
                :speed

  def initialize(attributes={})
    attributes.each do |name, value|
      public_send("#{name}=", value)
    end
  end

  def spawn
    Monster.new(self)
  end
end

class Monster
  attr_reader :definition
  attr_accessor :health

  def initialize(definition)
    @definition = definition
    @health = definition.max_hit_points
  end
end

gnome_def = MonsterDefinition.new(
  name: "gnome",
  attack_text: "attacks you with a pickaxe!",
  max_hit_points: 8,
  strength: 5,
  speed: 9)

g = gnome_def.spawn
# => #<Monster:0x0000000401e268
# @definition=
# #<MonsterDefinition:0x0000000401e9e8
# @attack_text="attacks you with a pickaxe!",
# @max_hit_points=8,
# @name="gnome",
# @speed=9,
# @strength=5>,
# @health=8>

This approach seems promising. But as we reflect on it, we realize that we’re probably going to keep adding more of these definition/instance pairs of classes. RoomDefinition / Room, ItemDefinition / Item, etc. This feels like an awful lot of ceremony.

Finally, we hit upon using the Prototype Pattern. In this version, there is only one class: Monster. It has slots for both static attributes (like name, and strength), and dynamic attributes like health.

class Monster
  attr_accessor :name,
                :attack_text,
                :max_hit_points,
                :strength,
                :speed,
                :health

  def initialize(attributes={})
    attributes.each do |name, value|
      public_send("#{name}=", value)
    end
  end

  def initialize_dup(prototype)
    self.health = prototype.max_hit_points
    super
  end
end

To initialize our game’s bestiary of possible monster types, we load up the YAML-formatted monster file and initialize a Monster for each entry. Dynamic attributes like health are left blank for now. These are our prototypes.

require 'yaml'
bestiary = YAML.load_file('monsters.yml').each_with_object({}) do
  |(name, attributes), collection|
  collection[name] = Monster.new(attributes.merge(name: name))
end

When we want to set up a player encounter with a monster, we simply find the appropriate prototype monster, and duplicate it. The customized #initialize_dup method in Monster takes care of setting up an initial health meter for the cloned monster.

rabbit = bestiary['rabbit'].dup
# => #<Monster:0x00000000fbd948
# @attack_text="bites you with sharp, pointy teeth!",
# @max_hit_points=50,
# @name="rabbit",
# @speed=50,
# @strength=50>

we can easily generate random monsters:

random_foe = bestiary.values.sample.dup
# => #<Monster:0x00000000fc21f0
# @attack_text="attacks you with a pickaxe!",
# @max_hit_points=12,
# @name="troll",
# @speed=5,
# @strength=10>

This solution is both shorter and simpler than any of the others we tried.

The Prototype Pattern is, in my experience, one of the more overlooked of the Gang of Four patterns. It is useful in many situations. As another example, consider a web application where administrators build form templates and then users fill out the forms. One way to model this is to populate the form builder interface FormDefinition objects, containing instances of TextFieldDefinition, CheckboxFieldDefinition, DateFieldDefinition, and so on. Then, when the form definition is complete and ready for user input, a new Form object is created, using the FormDefinition as a guide, with TextField, CheckboxField, DateField, etc. objects “inside” of it.

If we apply the Prototype Pattern to this problem, we once again do away with the definition/instance dichotomy. Instead, building a new form simply means assembling a Form object, where all of the form fields have empty or placeholder values. (This makes it exceptionally easy to show a live preview of the form as it is being built). The form is published by turning on a flag marking it as a “master” form. Whenever a user fills out the form, they are really filling out a duplicate of the master.

Design Patterns says that the Prototype Pattern is appropriate:

when a system should be should be independent of how its products are created, composed, and represented, and

• when the classes to instantiate are specified at run-time, for example, by dynamic loading; or
• to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or
• when instances of a class can have only one of a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.

The class-based view vs. the prototype-based view of OO represent a philosophical divide in how we model the world in software. We can learn from both points of view. But the lessons of the prototype-oriented mindset are not merely philosophical ones for users of class-based languages. The Prototype Pattern is a way to apply prototypes in a class-based system, one that can slash through complicated parallel inheritance hierarchies and provide a simple, flexible, and dynamic alternative. Questions? Comments? Have experience implementing the prototype pattern in your own applications? Pipe up in the comments! Oh, and do check out the article I wrote for Practicing Ruby. I had a blast metaprograming Ruby into behaving more like Self 🙂