The Pokémon type system consists of seventeen different types (Rock, Grass, Ice, Psychic, Ground, Bug, Flying, Fire, Fighting, Dark, Dragon, Poison, Water, Ghost, Normal, Electric, and Steel) that interact like an extended version of Rock-Paper-Scissors: for example, the Fire type is strong against the Grass type but weak against the Water type. In the table below, we've recorded the relative strengths of each of the types in the Pokémon type system; the number in each cell indicates how effective an attack of the type in the row is against a Pokémon of the type in the column. We call these numbers susceptibilities.

In the Pokémon games, only four susceptibility values (two, one, one-half, and zero) occur. These numbers indicate particularly high susceptibility, average susceptibility, particularly low susceptibility, and no susceptibility (immunity).

• The susceptibility of Flying types against Ground is 0, because Ground attacks cannot hurt Flying pokémon at all. The damage that a Ground type attack normally does is multiplied by 0 when it is used against a Flying type pokémon.
• The susceptibility of Fire types against Water attacks is 2, because Water type attacks are strong against Fire type Pokémon. The damage that a Water type attack normally does is doubled when it is used against a Fire type pokémon.
• The susceptibility of Water types against Water attacks is \(\frac{1}{2}\), because Water type attacks are weak against Water type Pokémon. The damage that a Water type attack normally does is halved when it is used against a Water type pokémon.

There are two pokémon type systems in use. The first is the classic system which was used for the very first pokémon games, Red, Yellow, and Blue. This old system was used from 1998 to 2000 in America, and is known as the Generation I Type System. The modern pokémon type system was introduced in 2000 with the introduction of pokémon Gold and Silver, and has been in use ever since. It is called the Generation II Type System.

The definitions of the two Type Systems are included below.

After creating the Pokémon types namespace, we store the tables of susceptibilities above in pokemon-table-gen-one and pokemon-table-gen-two, each of which is a simple vector of vectors. Because a vector of vectors can be cumbersome, we do not access the tables directly; instead, we use the derivative structures attack-strengths and defense-strengths, which are functions which return hash-maps associating each row (respectively column) of the table with its corresponding Pokémon type.

(ns pokemon.types
  (:use clojure.set)
;;  (:use clojure.contrib.combinatorics)
  (:use clojure.math.combinatorics)
  (:use clojure.math.numeric-tower)
;;  (:use clojure.contrib.def)
  (:use rlm.rlm-commands)
  (:require rlm.map-utils))

(in-ns 'pokemon.types)
;; record type strengths as a vector of vectors
;; the variables pokemon-table-gen-one and pokemon-table-gen-two 
;; are replaced with the tables above when this file is tangled.
(def pokemon-gen-one pokemon-table-gen-one)
(def pokemon-gen-two pokemon-table-gen-two)

(defn type-names [] 
  (vec (doall (map (comp keyword first) pokemon-gen-two))))

(defn attack-strengths []
     (zipmap
      (type-names)
      (map (comp vec rest) pokemon-gen-two))) 

(defn defense-strengths []
     (zipmap (type-names)
             (map
              (apply juxt (map (attack-strengths) (type-names)))
              (range (count (type-names))))))

The two statements

(def pokemon-gen-one pokemon-table-gen-one)
(def pokemon-gen-two pokemon-table-gen-two)

probably look weird. When the actual source file is created, those variables are replaced with the data from the tables above.

See types.clj to look at the final tangled output.

(clojure.pprint/pprint pokemon.types/pokemon-gen-two)

(("normal" 1 1 1 1 1 1 1 1 1 1 1 1 0.5 0 1 1 0.5)
 ("fire" 1 0.5 0.5 1 2 2 1 1 1 1 1 2 0.5 1 0.5 1 2)
 ("water" 1 2 0.5 1 0.5 1 1 1 2 1 1 1 2 1 0.5 1 1)
 ("electric" 1 1 2 0.5 0.5 1 1 1 0 2 1 1 1 1 0.5 1 1)
 ("grass" 1 0.5 2 1 0.5 1 1 0.5 2 0.5 1 0.5 2 1 0.5 1 0.5)
 ("ice" 1 0.5 0.5 1 2 0.5 1 1 2 2 1 1 1 1 2 1 0.5)
 ("fighting" 2 1 1 1 1 2 1 0.5 1 0.5 0.5 0.5 2 0 1 2 2)
 ("poison" 1 1 1 1 2 1 1 0.5 0.5 1 1 1 0.5 0.5 1 1 0)
 ("ground" 1 2 1 2 0.5 1 1 2 1 0 1 0.5 2 1 1 1 2)
 ("flying" 1 1 1 0.5 2 1 2 1 1 1 1 2 0.5 1 1 1 0.5)
 ("psychic" 1 1 1 1 1 1 2 2 1 1 0.5 1 1 1 1 0 0.5)
 ("bug" 1 0.5 1 1 2 1 0.5 0.5 1 0.5 2 1 1 0.5 1 2 0.5)
 ("rock" 1 2 1 1 1 2 0.5 1 0.5 2 1 2 1 1 1 1 0.5)
 ("ghost" 0 1 1 1 1 1 1 1 1 1 2 1 1 2 1 0.5 0.5)
 ("dragon" 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 0.5)
 ("dark" 1 1 1 1 1 1 0.5 1 1 1 2 1 1 2 1 0.5 0.5)
 ("steel" 1 0.5 0.5 0.5 1 2 1 1 1 1 1 1 2 1 1 1 0.5))

pokemon-gen-two is a simple list-of-lists data structure.

(clojure.pprint/pprint (pokemon.types/defense-strengths))

{:water [1 0.5 0.5 2 2 0.5 1 1 1 1 1 1 1 1 1 1 0.5],
 :psychic [1 1 1 1 1 1 0.5 1 1 1 0.5 2 1 2 1 2 1],
 :dragon [1 0.5 0.5 0.5 0.5 2 1 1 1 1 1 1 1 1 2 1 1],
 :fire [1 0.5 2 1 0.5 0.5 1 1 2 1 1 0.5 2 1 1 1 0.5],
 :ice [1 2 1 1 1 0.5 2 1 1 1 1 1 2 1 1 1 2],
 :grass [1 2 0.5 0.5 0.5 2 1 2 0.5 2 1 2 1 1 1 1 1],
 :ghost [0 1 1 1 1 1 0 0.5 1 1 1 0.5 1 2 1 2 1],
 :poison [1 1 1 1 0.5 1 0.5 0.5 2 1 2 0.5 1 1 1 1 1],
 :flying [1 1 1 2 0.5 2 0.5 1 0 1 1 0.5 2 1 1 1 1],
 :normal [1 1 1 1 1 1 2 1 1 1 1 1 1 0 1 1 1],
 :rock [0.5 0.5 2 1 2 1 2 0.5 2 0.5 1 1 1 1 1 1 2],
 :electric [1 1 1 0.5 1 1 1 1 2 0.5 1 1 1 1 1 1 0.5],
 :ground [1 1 2 0 2 2 1 0.5 1 1 1 1 0.5 1 1 1 1],
 :fighting [1 1 1 1 1 1 1 1 1 2 2 0.5 0.5 1 1 0.5 1],
 :dark [1 1 1 1 1 1 2 1 1 1 0 2 1 0.5 1 0.5 1],
 :steel [0.5 2 1 1 0.5 0.5 2 0 2 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5],
 :bug [1 2 1 1 0.5 1 0.5 1 0.5 2 1 1 2 1 1 1 1]}

defense-strengths is a more convenient form of pokemon-gen-two, with key/value pair access.

In the pokémon games, a pokémon can have up to two types at the same time. For example, Zapdos, the fearsome legendary bird that can control lightning, has both the Electric and Flying types. A pokémon with more than one type gains the advantages and disadvantages of both types. The susceptibilities of each type are multiplied together to produce the hybrid type's susceptibilities. For example, Electric is weak to Ground (susceptibility of 2), but Flying is immune to Ground (susceptibility of 0). Zapdos' type, Electric/Flying, is immune to Ground because \(2 \times 0 = 0\).

(in-ns 'pokemon.types)

(defn multitypes "All combinations of up to n types" [n]
  (vec
   (map vec
        (reduce concat
                (map (partial combinations (type-names))
                     (range 1 (inc n)))))))

(defn susceptibility 
  "Hash-map of the susceptibilities of the given type combination 
   to each type of attack"
  [pkmn-types]
  (rlm.map-utils/map-vals
   clojure.core/rationalize 
   (apply hash-map
          (interleave (type-names)
                      (apply (partial map *) 
                             (map (defense-strengths) pkmn-types))))))
  
(defn susceptance 
  "The cumulative susceptibility of the given type combination"
  [types]
  (reduce + (map #(expt % 2) (vals (susceptibility types)))))

Now we can work out the susceptibility of Zapdos automatically.

Electric is weak to Ground.

(:ground (pokemon.types/susceptibility [:electric]))

2

Flying is immune to Ground.

(:ground (pokemon.types/susceptibility [:flying]))

0

Together, they are immune to Ground.

(:ground (pokemon.types/susceptibility [:electric :flying]))

0

I'd like to find type combinations that are interesting, but the total number of combinations gets huge as we begin to consider more types. For example, the total possible number of type combinations given just 8 possible types is: 17⁸ = 6,975,757,441 combinations. Therefore, it's prudent to use search.

These functions are a simple implementation of best-first search in clojure. The idea is to start off with a collection of nodes and some way of finding the best node, and to always expand the best node at every step.

(in-ns 'pokemon.types)

(defn comparatize
  "Define a comparator which uses the numerical outputs of
   fn as its criterion.  Objects are sorted in increasing
   numerical order. Objects with the same fn-value are
   further compared by clojure.core/compare."
  [fun]
  (fn [a b]
    (let [val-a (fun a)
          val-b (fun b)]
      (cond
       ;; if the function cannot differentiate the two values
       ;; then compare the two values using clojure.core/compare
       (= val-a val-b) (compare a b)
       true
       ;; LOWER values of the function are preferred
       (compare (- val-a val-b) 0)))))

(defn best-first-step [successors [visited unvisited]]
  (cond (empty? unvisited) nil
        true
        (let [best-node (first unvisited)
              visited* (conj visited best-node)
              unvisited*
              (difference
               (union unvisited (set (successors best-node)))
               visited*)]
          (println best-node)
          [visited* unvisited*])))
(alter-var-root #'best-first-step memoize)

;; memoize partial from core so that for example 
;; (= (partial + 1) (partial + 1))
;; this way, best first search can take advantage of the memoization
;; of best-first step
(undef partial)
(def partial (memoize clojure.core/partial))

(defn best-first-search
  "Searches through a network of alternatives, pursuing
   initially-promising positions first. Comparator defines
   which positions are more promising, successors produces a
   list of improved positions from the given position (if
   any exist), and initial-nodes is a list of starting
   positions.  Returns a lazy sequence of search results
   [visited-nodes unvisited-nodes], which terminates when
   there are no remaining unvisited positions."
  [comparator successors initial-nodes]
  (let [initial-nodes
        (apply (partial sorted-set-by comparator) initial-nodes)
        initial-visited-nodes (sorted-set-by comparator)
        step (partial best-first-step successors)]
    (take-while
     (comp not nil?)
     (iterate step [initial-visited-nodes initial-nodes]))))

Now that we have a basic best-first-search, it's convenient to write a few pokémon-type specific convenience functions.

(in-ns 'pokemon.types)
(def type-compare
  "compare two type combinations W.R.T. their susceptibilities"
  (comparatize susceptance))

(defn type-successors
  "Return the set of types that can be made by appending a
single type to the given combination."
  [type]
  (if (nil? type) '()
      (set (map (comp vec sort (partial into type)) (multitypes 1)))))

(defn immortal?
  "A type combo is immortal if it is resistant or
  invulnerable to every pokemon type. This is because that
  set of types can just be repeated to achieve as low a
  susceptance as desired"
  [type]
  (every? (partial > 1) (vals (susceptibility type))))

(defn type-successors*
  "Stop expanding a type if it's immortal, or if it is
longer than or equal to limit-size.  Also, only return type
additions that are strictly better than the initial type."
  [limit-size type]
  (if (or (<= limit-size (count type)) (immortal? type)) '()
      (set (filter #(< 0 (type-compare type %)) 
                   (type-successors type)))))

(defn pokemon-type-search
  "Search among type-combos no greater than length n,
limited by limit steps of best-first-search."
  ([n] (pokemon-type-search n Integer/MAX_VALUE))
  ([n limit]
     (first (last
             (take
              limit
              (best-first-search
               type-compare
               (partial type-successors* n)
               (multitypes 1)))))))
         
(def immortals
  "find all the immortal pokemon types."
  (comp (partial filter immortal?) pokemon-type-search))

Because there are so many type combinations, it's important to narrow down the results as much as possible. That is why type-successors* only returns types that are actually better than the type it is given.

Best-first search can get caught optimizing a single type forever, so it's also important to limit the search space to be finite by setting an upper bound on the length of a type combo.

Searching for a type that is weak to everything takes a very long time and fails to reveal any results. That's the problem with a search over this large problem space — if there's an easy solution, the search will find it quickly, but it can be very hard to determine whether there is actually a solution.

In the next installment, I'll use lp_solve to solve this problem in a different way.