squib 0.11.0 → 0.12.0

data/docs/dsl/disable_build_globally.rst

@@ -0,0 +1,46 @@
+disable_build_globally
+======================
+
+Disable the given build group for all future ``Squib::Deck`` runs.
+
+Essentially a convenience method for setting the ``SQUIB_BUILD`` environment variable. See :doc:`/build_groups` for ways to use this effectively.
+
+This is a member of the ``Squib`` module, so you must run it like this::
+
+  Squib.disable_build_globally :pdf
+
+The intended purpose of this method is to be able to alter the environment from other build scripts, such as a Rakefile.
+
+Required Arguments
+------------------
+
+build_group_name
+
+  the name of the build group to disable. Convention is to use a Ruby symbol.
+
+
+Examples
+--------
+
+Can be used to disable a group, overriding setting the environment variable at the command line::
+
+  Squib.enable_build_globally :pdf
+  Squib.disable_build_globally :pdf
+
+  Squib::Deck.new do
+    build :pdf do
+      save_pdf #does not get run regardless of incoming environment
+    end
+  end
+
+But gets overridden by an individual ``Squib::Deck`` programmatically enabling a build via :doc:`/dsl/enable_build`::
+
+  Squib.enable_build_globally :pdf
+  Squib.disable_build_globally :pdf
+
+  Squib::Deck.new do
+    enable_build :pdf
+    build :pdf do
+      save_pdf # this will be run no matter what
+    end
+  end

data/docs/dsl/enable_build.rst

@@ -1,7 +1,7 @@
 enable_build
 ============
 
-Enable the given build group for the rest of the build. Thus, code within the corresponding :doc:`/dsl/group` block will be executed. See :doc:`/build_groups` for ways to use this effectively.
+Enable the given build group for the rest of the build. Thus, code within the corresponding :doc:`/dsl/build` block will be executed. See :doc:`/build_groups` for ways to use this effectively.
 
 
 Required Arguments

data/docs/dsl/enable_build_globally.rst

@@ -0,0 +1,44 @@
+disable_build_globally
+======================
+
+Enagle the given build group for all future ``Squib::Deck`` runs.
+
+Essentially a convenience method for setting the ``SQUIB_BUILD`` environment variable. See :doc:`/build_groups` for ways to use this effectively.
+
+This is a member of the ``Squib`` module, so you must run it like this::
+
+  Squib.enable_build_globally :pdf
+
+The intended purpose of this method is to be able to alter the environment from other build scripts, such as a Rakefile.
+
+Required Arguments
+------------------
+
+build_group_name
+
+  the name of the build group to enable. Convention is to use a Ruby symbol.
+
+
+Examples
+--------
+
+Can be used to enable a group, overriding setting the environment variable at the command line::
+
+  Squib.enable_build_globally :pdf
+
+  Squib::Deck.new do
+    build :pdf do
+      save_pdf # this runs regardless of incoming environment
+    end
+  end
+
+But gets overridden by an individual ``Squib::Deck`` programmatically enabling a build via :doc:`/dsl/enable_build`::
+
+  Squib.enable_build_globally :pdf
+
+  Squib::Deck.new do
+    disable_build :pdf
+    build :pdf do
+      save_pdf # this will NOT be run no matter what
+    end
+  end

data/docs/dsl/save_pdf.rst

@@ -1,13 +1,11 @@
 save_pdf
 ========
 
-Lays out the cards in range on a sheet and renders a PDF
+Lays out the cards in a gride and renders a PDF.
 
 Options
 -------
 
-
-
 file
   default: ``'output.pdf'``
 
@@ -43,6 +41,49 @@ trim
 
   the space around the edge of each card to trim (e.g. to cut off the bleed margin for print-and-play). Supports :doc:`/units`.
 
+crop_marks
+  default: ``false``
+
+  When ``true``, draws lines in the margins as guides for cutting. Crop marks factor in the ``trim`` (if non-zero), and can also be customized via ``crop_margin_*`` options (see below). Has no effect if ``margin`` is 0.
+
+.. warning::
+
+  Enabling this feature will draw lines to the edge of the page. Most PDF Readers, by default, will recognize this and scale down the entire PDF to fit in those crop marks - throwing off your overall scale. To disable this, you will need to set Print Scaling "Use original" or "None" when you go to print (this looks different for different PDF readers). Be sure to test this out before you do your big print job!!
+
+crop_margin_bottom
+  default: 0
+
+  The space between the bottom edge of the (potentially trimmed) card, and the crop mark. Supports :doc:`/units`. Has no effect if ``crop_marks`` is ``false``.
+
+crop_margin_left
+  default: 0
+
+  The space between the left edge of the (potentially trimmed) card, and the crop mark. Supports :doc:`/units`. Has no effect if ``crop_marks`` is ``false``.
+
+crop_margin_right
+  default: ``0``
+
+  The space between the right edge of the (potentially trimmed) card, and the crop mark. Supports :doc:`/units`. Has no effect if ``crop_marks`` is ``false``.
+
+crop_margin_top
+  default: ``0``
+
+  The space between the top edge of the (potentially trimmed) card, and the crop mark. Supports :doc:`/units`. Has no effect if ``crop_marks`` is ``false``.
+
+crop_stroke_color
+  default: ``:black``
+
+  The color of the crop mark lines. Has no effect if ``crop_marks`` is ``false``.
+
+crop_stroke_dash
+  default: ``''``
+
+  Define a dash pattern for the crop marks. This is a special string with space-separated numbers that define the pattern of on-and-off alternating strokes, measured in pixels or units. For example, ``'0.02in 0.02in'`` will be an equal on-and-off dash pattern. Supports :doc:`/units`. Has no effect if ``crop_marks`` is ``false``.
+
+crop_stroke_width
+  default: ``1.5``
+
+  Width of the crop mark lines. Has no effect if ``crop_marks`` is ``false``.
 
 Examples
 --------

data/docs/dsl/showcase.rst

@@ -63,3 +63,14 @@ file
 
 Examples
 --------
+
+This sample `lives here <https://github.com/andymeneely/squib/tree/master/samples/saves>`_.
+
+.. literalinclude:: ../../samples/saves/_showcase.rb
+  :language: ruby
+  :linenos:
+
+.. raw:: html
+
+  <img src="../saves/showcase_expected.png" class="figure">
+  <img src="../saves/showcase2_expected.png" class="figure">

data/docs/dsl/text.rst

@@ -18,7 +18,7 @@ str
 font
   default: ``'Arial 36'``
 
-  the Font description string, including family, styles, and size. (e.g. ``'Arial bold italic 12'``). For the official documentation, see the `Pango docs <http://ruby-gnome2.sourceforge.jp/hiki.cgi?Pango%3A%3AFontDescription#style>)`_. This `description <http://www.pygtk.org/pygtk2reference/class-pangofontdescription.html>`_ is also quite good.
+  the Font description string, including family, styles, and size. (e.g. ``'Arial bold italic 12'``). For the official documentation, see the `Pango font string docs <http://ruby-gnome2.sourceforge.jp/hiki.cgi?Pango%3A%3AFontDescription#style>`_. This `description <http://www.pygtk.org/pygtk2reference/class-pangofontdescription.html>`_ is also quite good.
 
 font_size
   default: ``nil``
@@ -116,7 +116,7 @@ Markup
 
 If you want to do specialized formatting within a given string, Squib has lots of options. By setting ``markup: true``, you enable tons of text processing. This includes:
 
-  * Pango Markup. This is an HTML-like formatting language that specifies formatting inside your string. Pango Markup essentially supports any formatting option, but on a letter-by-letter basis. Such as: font options, letter spacing, gravity, color, etc. See the `Pango docs  <https://developer.gnome.org/pango/stable/PangoMarkupFormat.html>`_ for details.
+  * Pango Markup. This is an HTML-like formatting language that specifies formatting inside your string. Pango Markup essentially supports any formatting option, but on a letter-by-letter basis. Such as: font options, letter spacing, gravity, color, etc. See the `Pango markup docs  <https://developer.gnome.org/pango/stable/PangoMarkupFormat.html>`_ for details.
   * Quotes are converted to their curly counterparts where appropriate.
   * Apostraphes are converted to curly as well.
   * LaTeX-style quotes are explicitly converted (````like this''``)
@@ -289,6 +289,4 @@ angle
 Examples
 --------
 
-.. raw:: html
-
-  <script src="https://gist.github.com/andymeneely/52d7b8e332194946bc69.js"></script>
+See :doc:`/text_feature`.

data/docs/dsl/xlsx.rst

@@ -48,3 +48,9 @@ The ``xlsx`` method also takes in a block that will be executed for each cell in
 
 Examples
 --------
+
+To get the sample Excel files, go to `its source <https://github.com/andymeneely/squib/tree/dev/samples/data>`_
+
+.. literalinclude:: ../../samples/data/_excel.rb
+  :language: ruby
+  :linenos:

data/docs/guides/game_icons.rst

@@ -1,6 +1,126 @@
-Using GameIcons.net
-===================
+Squib + Game-Icons.net
+======================
 
-.. note::
+I believe that, in prototyping, you want to focus on getting your idea to the table as fast as possible. Artwork is the kind of thing that can wait for later iterations once you know your game is a good one.
 
-  To be written
+But! Playtesting with just text is a real drag.
+
+Fortunately, there's this amazing project going on over at http://game-icons.net. They are in the process of building a massive library of gaming-related icons.
+
+As a sister project to Squib, I've made a Ruby gem that interfaces with the Game Icons library. With this gem, you can access Game Icons files, and even manipulate them as they go into your game.
+
+Here are some instructions for working with the Game Icons gem into Squib.
+
+Install the Gem
+---------------
+
+To get the gem, do:
+
+  $ gem install game_icons
+
+The library update frequently, so it's a good idea to upgrade whenever you can.
+
+  $ gem up game_icons
+
+If you are using Bundler, go ahead and put this in your Gemfile::
+
+  gem 'game_icons'
+
+And then run ``bundle install`` to install it from there.
+
+The ``game_icons`` gem has no required dependencies. However, if you want to manipulate the SVG
+
+To begin using the gem, just require it::
+
+  require 'game_icons'
+
+Find Your Icon
+--------------
+
+Game-Icons.net has a search engine with some great tagging. Find the icon that you need. The gem will need the "name" of your icon. You can get this easily from the URL. For example:
+
+  http://game-icons.net/lorc/originals/meat.html
+
+could be called::
+
+  'meat'
+  :meat
+
+Symbols are okay too (really, anything that responds to ``to_s`` will suffice). Spaces are replaced with a dash::
+
+  'police-badge'
+  :police_badge
+
+However, some icons have the same name but different authors. To differentiate these, you put the author name before a slash. Like this::
+
+  'lorc/meat'
+  'andymeneely/police-badge'
+
+To get the Icon, you use ``GameIcons#get``::
+
+  GameIcons.get(:meat)
+  GameIcons.get('lorc/meat')
+  GameIcons.get(:police_badge)
+  GameIcons.get('police-badge')
+  GameIcons.get('andymeneely/police-badge')
+
+If you want to know all the icon names, you can always use::
+
+  GameIcons.names # returns the list of icon names
+
+If you end up misspelling one, the gem will suggest one:
+
+.. code-block:: shell
+
+    irb(main):005:0> GameIcons.get(:police_badg)
+    RuntimeError: game_icons: could not find icon 'police_badg'. Did you mean any of these? police-badge
+
+Use the SVG File
+----------------
+
+If you just want to use the icon in your game, you can just use the ``file`` method::
+
+  svg file: GameIcons.get(:police-badge).file
+
+Recolor the SVG file
+--------------------
+
+The gem will also allow you to recolor the icon as you wish, setting foreground and background::
+
+  # recolor foreground and background to different shades of gray
+  svg data: GameIcons.get('glass-heart').
+                      recolor(fg: '333', bg: 'ccc').
+                      string
+
+  # recolor with opacity
+  svg data: GameIcons.get('glass-heart').
+                      recolor(fg: '333', bg: 'ccc',
+                              fg_opacity: 0.25, bg_opacity: 0.75).
+                      string
+
+Use the SVG XML Data
+--------------------
+
+SVGs are just XML files, and can be manipulated in their own clever ways. GameIcons is super-consistent in the way they format their SVGs - the entire icon is flattened into one path. So you can manipulate how the icon looks in your own way. Here's an example of using straight string substitution::
+
+  svg data: GameIcons.get(:meat).string.gsub('fill="#fff"', 'fill="#abc"')
+
+Here's a fun one. It replaces all non-white colors in your SVG with black through the SVG::
+
+  svg data: GameIcons.get(:meat).string.gsub(':#ffffff', 'snarfblat').
+                                        gsub(/:#[0-9a-f]{6}/, ':#000000').
+                                        gsub('snarfblat', ':#ffffff')
+
+XML can also be manipulated via CSS or XPATH queries via the ``nokogiri`` library, which Squib has as a dependency anyway. Like this::
+
+  doc = Nokogiri::XML(GameIcons.get(:meat).string)
+  doc.css('path')[1]['fill'] = #f00 # set foreground color to red
+  svg data: doc.to_xml
+
+
+Path Weirdness
+--------------
+
+Inkscape and Squib's libRSVG renderer can lead to unexpected results for some icons. This has to do with a discrepancy in how path data is interpreted according to the specification. (Specifically, negative numbers need to have a space before them in the path data.) The fix for this is quick and easy, and the gem can do this for you::
+
+  GameIcons.get(:sheep).correct_pathdata.string # corrects path data

data/docs/guides/getting-started/part_1_zero_to_game.rst

@@ -1,9 +1,11 @@
 The Squib Way pt 1: Zero to Game
 =================================
 
-.. warning::
+I've always felt that the Ruby community and the tabletop game design community had a lot in common, and a lot to learn from each other. Both are all about testing. All about iterative development. Both communities are collegial, creative, and fun.
 
-  Conversion from markdown not finished yet
+But the Ruby community, and the software development community generally, has a lot to teach us game designers about how to develop something. `Ruby has a "way" of doing things <http://therubyway.io/>`_ that is unique and helpful to game designers.
+
+In this series of guides, I'll introduce you to Squib's key features and I'll walk you through a basic prototype. We'll also take a more circuitous route than normal so that I can touch upon some key design principles and good software development habits so that you can make your Squib scripts maintainable, understandable, flexible, and changeable.
 
 Prototyping with Squib
 ----------------------
@@ -14,7 +16,6 @@ The key to prototyping tabletop games is *playtesting*. At the table. With human
 
 But! We also want to get the *second* (and third and fourth and fifth...) version of our game back to the playtesting table quickly, too. If we work with Squib from day one, our ability to react to feedback will be much smoother once we've laid the groundwork.
 
-In this series of guides, we'll introduce you to Squib's key features by also walking you through a basic prototype. We'll take a more circuitous route than normal so we can pick apart what Squib is actually doing so that we can leverage its features.
 
 Get Installed and Set Up
 -----------------------------

data/docs/guides/getting-started/part_2_iconography.rst

@@ -1,10 +1,6 @@
 The Squib Way pt 2: Iconography
 ===================================
 
-.. warning::
-
-  This chapter is still being written
-
 In the previous guide, we walked you through the basics of going from ideas in your head to a very simple set of cards ready for playtesting at the table. In this guide we take the next step: creating a visual language.
 
 Art: Graphic Design vs. Illustration
@@ -30,7 +26,7 @@ The majority of the cards in RFTG have no description text on them, and yet the
 
 But once you know the structure of the game and what various bonuses mean, you can understand new cards very easily. Icons are combined in creative ways to show new bonuses. Text is used only when a bonus is much more complicated than what can be expressed with icons. Icons are primarily arranged along left side of the card so you can hold them in your hand and compare bonuses across cards quickly. All of these design decisions match the gameplay nicely because the game consists of a lot of scrolling through cards in your hand and evaluating which ones you want to play.
 
-Go check out images of Race for the Galaxy `on BoardGameGeek.com <https://boardgamegeek.com/boardgame/28143/race-galaxy>`_.
+Go check out `images of Race for the Galaxy on BoardGameGeek.com <https://boardgamegeek.com/boardgame/28143/race-galaxy>`_.
 
 Dominion
 ^^^^^^^^
@@ -50,16 +46,17 @@ Squib is good for supporting any kind of layout you can think of, but it's also
   * :doc:`/dsl/png` method, and all of its features like blending operators, alpha transparency, and masking
   * Layout files allow multiple icons for one data column (see :doc:`/layouts`)
   * Layout files also have the ``extends`` feature that allows icons to inherit details from each other
-  * The ``range`` option on :doc:`/dsl/text`, :doc:`/dsl/svg`, and :doc:`/dsl/png` allows you to specify text and icons for any subset of your files
+  * The ``range`` option on :doc:`/dsl/text`, :doc:`/dsl/svg`, and :doc:`/dsl/png` allows you to specify text and icons for any subset of your cards
   * The :doc:`/dsl/text` method allows for embedded icons.
-  * Ruby provides neat ways of aggregating data with ``inject``, ``map``, and ``zip`` that supports iconography
+  * The :doc:`/dsl/text` method allows for Unicode characters (if the font supports it).
+  * Ruby provides neat ways of aggregating data with ``inject``, ``map``, and ``zip`` that gives you ultimate flexibility for specifying different icons for different cards.
 
 Back to the Example: Drones vs. Humans
 --------------------------------------
 
 Ok, let's go back to our running example, project ``arctic-lemming`` from Part 1. We created cards for playtesting, but we never put down the faction for each card. That's a good candidate for an icon.
 
-Let's get some stock icons for this exercise. For this example, I went to http://game-icons.net. I set my foreground color to black, and background to white. I then  downloaded "auto-repair.svg" and "backup.svg". I'm choosing not to rename the files so that I can find them again on the website if I need to. (If you want to know how to do this process DIRECTLY from Ruby, and not going to the website, check out my *other* Ruby gem called `game_icons <https://github.com/andymeneely/game_icons>`_ - it's tailor-made for Squib!)
+Let's get some stock icons for this exercise. For this example, I went to http://game-icons.net. I set my foreground color to black, and background to white. I then downloaded "auto-repair.svg" and "backup.svg". I'm choosing not to rename the files so that I can find them again on the website if I need to. (If you want to know how to do this process DIRECTLY from Ruby, and not going to the website, check out my *other* Ruby gem called `game_icons <https://github.com/andymeneely/game_icons>`_ - it's tailor-made for Squib! We've got some documentation in :doc:`/guides/game_icons`
 
 When we were brainstorming our game, we placed one category of icons in a single column ("faction"). Presumably, one would want the faction icon to be in the same place on every card, but a different icon depending on the card's faction. There are a couple of ways of accomplishing this in Squib. First, here some less-than-clean ways of doing it::
 
@@ -115,7 +112,7 @@ At this point, we've got a very scalable design for our future iterations. Let's
 Why Ruby+YAML+Spreadsheets Works
 --------------------------------
 
-In software design, a "good" design is one where the problem is broken down into a set of easier duties that each make sense on their own, where the interaction between duties is easy, and where to place new responsbilities is obvious.
+In software design, a "good" design is one where the problem is broken down into a set of easier duties that each make sense on their own, where the interaction between duties is easy, and where to place new responsibilities is obvious.
 
 In Squib, we're using automation to assist the prototyping process. This means that we're going to have a bunch of decisions and responsibilities, such as:
 
@@ -137,16 +134,95 @@ The best way to preserve this design is to try to keep the Ruby code clean. As w
 
 Ok, let's get back to this prototype.
 
-Icons for Some, But Not All, Cards
-----------------------------------
+Illustration: One per Card
+--------------------------
+
+The cards are starting to come together, but we have another thing to do now. When playtesting, you need a way of visually identifying the card immediately. Reading text takes an extra moment to identify the card - wouldn't it be nice if we had some sort of artwork, individualized to the card?
+
+Of course, we're not going to commission an artist or do our own oil paintings just yet. Let's get some placeholder art in there. Back to GameIcons, we're going to use "ninja-mask.svg", "pirate-skull.svg", "shambling-zombie.svg", and "robot-golem.svg".
+
+Method 1: Put the file name in data
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The difference between our Faction icon and our Illustration icon is that the Illustration needs to be different for every card. We already have a convenient way to do something different on every card - our CSV file!
+
+Here's how the CSV would look:
+
+.. raw:: html
+
+  <code data-gist-id="d2bb2eb028b27cf1dace"
+      data-gist-file="data_pt2_03.csv"></code>
+
+In our layout file we can center it in the middle of the card, nice and big. And then the Ruby & YAML would look like this:
+
+.. raw:: html
+
+  <code data-gist-id="d2bb2eb028b27cf1dace"
+      data-gist-file="_part2_03_illustrations.yml"
+      data-gist-highlight-line="12-16"></code>
+  <code data-gist-id="d2bb2eb028b27cf1dace"
+      data-gist-file="_part2_03_illustrations_m1.rb"
+      data-gist-highlight-line="14"></code>
+
+And our output will look like this:
+
+.. raw:: html
+
+  <code data-gist-id="d2bb2eb028b27cf1dace"
+      data-gist-file="_part2_03_illustrations_00.png"></code>
 
-.. note::
 
-  to be written
+Method 2: Map title to file name
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-One Column per Icon
--------------------
+There are some drawbacks to Method 1. First, you're putting artwork graphics info inside your game data. This can be weird and unexpected for someone new to your code (i.e. that person being you when you put your project down for a few months). Second, when you're working on artwork you'll have to look up what the name of every file is in your CSV. (Even writing this tutorial, I forgot that "zombie" is called "shambling-zombie.svg" and had to look it up, distracting me from focusing on writing.)
+
+There's another way of doing this, and it's more Ruby-like because it follows the `Convention over Configuration <https://en.wikipedia.org/wiki/Convention_over_configuration>`_ philosophy. The idea is to be super consistent with your naming so that you don't have to *configure* that, say, "pirate" has an illustration "pirate-skull". The illustration should be literally the title of the card - converted to lowercase because that's the convention for files. That means it should just be called "pirate.svg", and Squib should know to "just put an SVG that is named after the title". Months later, when you want to edit the illustration for pirate, you will probably just open "pirate.svg".
+
+To do this, you'll need to convert an array of Title strings from your CSV (``data['title']`` to an array of file names. Ruby's ``map`` was born for this.
 
 .. note::
 
-  to be written
+  If you're new to Ruby, here's a quick primer. The ``map`` method gets run on every element of an array, and it lets you specify a *block* (either between curly braces for one line or between ``do`` and ``end`` for multiple lines). It then returns another Array of the same size, but with every value mapped using your block. So::
+
+  [1, 2, 3].map { |x| 2 * x }             # returns [2, 4, 6]
+  [1, 2, 3].map { |x| "$#{x}" }           # returns ["$1", "$2", "$3"]
+  ['NARF', 'ZORT'].map { |x| x.downcase } # returns ['narf', 'zort']
+
+
+
+Thus, if we rename our illustration files from "pirate-skull.svg" to "pirate.svg", we can have CSV data that's JUST game data:
+
+.. raw:: html
+
+  <code data-gist-id="d2bb2eb028b27cf1dace"
+    data-gist-file="data.csv"
+    data-gist-highlight-line="14"></code>
+
+And our Ruby code will figure out the file name:
+
+.. raw:: html
+
+  <code data-gist-id="d2bb2eb028b27cf1dace"
+      data-gist-file="_part2_03_illustrations_m2.rb"
+      data-gist-highlight-line="3,14-15"></code>
+
+And our output images look identical to Method 1.
+
+Learn by Example
+----------------
+
+In my game, Your Last Heist, I use some similar methods as above:
+
+  * `Use a different background depending <https://github.com/andymeneely/project-timber-wolf/blob/156a5d417dd8021e3f391a67c08b8e9f06f58c2b/src/characters.rb#L14-L16>`_ on if the character is level 1 or 2. Makes use of `Ruby's ternary operator <https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Control_Structures#short-if_expression_.28aka_ternary_operator.29>`_.
+  * `Only put an image if the data is non-nil <https://github.com/andymeneely/project-timber-wolf/blob/156a5d417dd8021e3f391a67c08b8e9f06f58c2b/src/characters.rb#L19-L21>`_. Some characters have a third skill, others do not. Only load a third skill image if they have a third skill. This line leverages the fact that when you do ``svg file: nil``, the ``svg`` simply does nothing.
+  * `Method 2 from above, but into its own directory <https://github.com/andymeneely/project-timber-wolf/blob/156a5d417dd8021e3f391a67c08b8e9f06f58c2b/src/characters.rb#L23>`_.
+  * `Use different-sized backdrops depending on the number of letters in the text <https://github.com/andymeneely/project-timber-wolf/blob/156a5d417dd8021e3f391a67c08b8e9f06f58c2b/src/characters.rb#L24-L31>`_. This one is cool because I can rewrite the description of a card, and it will automatically figure out which backdrop to use based on how many letters the text has. This makes use of `Ruby's case-when expression <https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Control_Structures#case_expression>`_.
+  * After saving the regular cards, we end our script by `creating some annotated figures <https://github.com/andymeneely/project-timber-wolf/blob/156a5d417dd8021e3f391a67c08b8e9f06f58c2b/src/characters.rb#L68-L76>`_ for the rulebook by drawing some text on top of it and saving it using ``showcase``.
+
+Are We Done?
+------------
+
+At this stage, you've got most of what you need to build a game from prototype through completion. Between images and text, you can do pretty much anything. Squib does much more, of course, but these are the basic building blocks.
+
+But, prototyping is all about speed and agility. The faster you can get what you need, the sooner you can playtest, and the sooner you can make it better. Up next, we'll be looking at workflow: ways to help you get what you need quickly and reliably.