squib 0.12.0 → 0.13.0

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

@@ -1,228 +0,0 @@
-The Squib Way pt 2: Iconography
-===================================
-
-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
-------------------------------------
-
-A common piece of advice in the prototyping world is "Don't worry about artwork, just focus on the game and do the artwork later". That's good advice, but a bit over-simplified. What folks usually mean by "artwork" is really "illustration", like the oil painting of a wizard sitting in the middle of the card or the intricate border around the edges.
-
-But games are more than just artwork with text - they're a system of rules that need to be efficiently conveyed to the players. They're a *visual language*. When players are new to your game, the layout of the cards need to facilitate learning. When players are competing in their 30th game, though, they need the cards to maximize usability by reducing their memory load, moving gameplay along efficiently, and provide an overall aesthetic that conveys the game theme. That's what graphic design is all about, and requires a game designer's attention much more than commissioning an illustration.
-
-Developing the visual language on your cards is not a trivial task. It's one that takes a lot of iteration, feedback, testing, improvement, failure, small successes, and reverse-engineering. It's something you should consider in your prototype early on. It's also a series of decisions that don't necessarily require artistic ability - just an intentional effort applied to usability.
-
-Icons and the their placement are, perhaps, the most efficient and powerful tools in your toolbelt for conveying your game's world. In the prototyping process, you don't need to be worried about using icons that are your *final* icons, but you should put some thought into what the visuals will look like because you'll be iterating on that in the design process.
-
-Iconography in Popular Games
-----------------------------
-
-When you get a chance, I highly recommend studying the iconography of some popular games. What works for you? What didn't? What kinds of choices did the designers make that works *for their game*? Here are a few that come my mind:
-
-Race for the Galaxy
-^^^^^^^^^^^^^^^^^^^
-
-The majority of the cards in RFTG have no description text on them, and yet the game contains hundreds of unique cards. RFTG has a vast, rich visual iconography that conveys a all of the bonuses and trade-offs of a card efficiently to the user. As a drawback, though, the visual language can be intimidating to new players - every little symbol and icon means a new thing, and sometimes you just need to memorize that "this card does that", until you realize that the icons show that.
-
-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>`_.
-
-Dominion
-^^^^^^^^
-
-Unlike RFTG, Dominion has a much simpler iconography. Most of the bonuses are conveyed in a paragraph of text in the description, with a few classifications conveyed by color or format. The text has icons embedded in it to tie in the concept of Gold, Curses, or Victory Points.
-
-But Dominion's gameplay is much different: instead of going through tons of different cards, you're only playing with 10 piles of cards in front of you. So each game really just requires you to remember what 10 cards mean. Once you purchase a card and it goes into your deck, you don't need to evaluate its worth quickly as in RFTG because you already bought it. Having most of the game's bonuses in prose means that new bonuses are extremely flexible in their expression. As a result, Dominion's bonuses and iconography is much more about text and identifying known cards than about evaluating new ones.
-
-Go check out images of Dominion `on BoardGameGeek.com <https://boardgamegeek.com/boardgame/36218/dominion>`_
-
-How Squib Supports Iconography
-------------------------------
-
-Squib is good for supporting any kind of layout you can think of, but it's also good for supporting multiple ways of translating your data into icons on cards. Here are some ways that Squib provides support for your ever-evolving iconography:
-
-  * :doc:`/dsl/svg` method, and all of its features like scaling, ID-specific rendering, direct XML manipulation, and all that the SVG file format has to offer
-  * :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 cards
-  * The :doc:`/dsl/text` method allows for embedded icons.
-  * 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! 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::
-
-  svg range: 0, file: 'auto_repair.svg' # hard-coded range number? not flexible
-  svg range: 1, file: 'auto_repair.svg' # hard-coded range number? not flexible
-  svg range: 2, file: 'backup.svg'      # hard-coded range number? not flexible
-  svg range: 3, file: 'backup.svg'      # hard-coded range number? not flexible
-  # This gets very hard to maintain over time
-  svg file: ['auto_repair.svg', 'auto_repair.svg', 'backup.svg', 'backup.svg']
-  # This is slightly easier to maintain, but is more verbose and still hardcoded
-  svg range: 0..1, file 'auto_repair.svg'
-  svg range: 2..3, file 'backup.svg'
-
-That's too much hardcoding of data into our Ruby code. That's what layouts are for. Now, we've already specified a layout file in our prior example. Fortunately, Squib supports *multiple* layout files, which get combined into a single set of layout styles. So let's do that: we create our own layout file that defines what a ``human`` is and what a ``drone`` is. Then just tell ``svg`` to use the layout data. The data column is simply an array of factions, the icon call is just connecting the factions to their styles with::
-
-  svg layout: data['faction']
-
-So, putting it all together, our code looks like this.
-
-.. raw:: html
-
-  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
-  <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/gist-embed/2.4/gist-embed.min.js"></script>
-  <code data-gist-id="d2bb2eb028b27cf1dace"
-        data-gist-file="_part2_01_factions.rb"
-        data-gist-highlight-line="13"
-        ></code>
-  <code data-gist-id="d2bb2eb028b27cf1dace"
-        data-gist-file="_part2_01_factions.yml"></code>
-  <code data-gist-id="d2bb2eb028b27cf1dace" data-gist-file="data.csv"></code>
-  <code data-gist-id="d2bb2eb028b27cf1dace"
-        data-gist-file="_part2_01_factions_00.png"></code>
-
-**BUT!** There's a very important software design principle we're violating here. It's called DRY: Don't Repeat Yourself. In making the above layout file, I hit copy and paste. What happens later when we change our mind and want to move the faction icon!?!? We have to change TWO numbers. Blech.
-
-There's a better way: ``extends``
-
-The layout files in Squib also support a special keyword, ``extends``, that allows us to "copy" (or "inherit") another style onto our own, and then we can override as we see fit. Thus, the following layout is a bit more DRY:
-
-.. raw:: html
-
-  <code data-gist-id="d2bb2eb028b27cf1dace"
-      data-gist-file="_part2_02_factions.yml"></code>
-
-Much better!
-
-Now if we want to add a new faction, we don't have to copy-pasta any code! We just extend from faction and call in our new SVG file. Suppose we add a new faction that needs a bigger icon - we can define our own ``width`` and ``height`` beneath the ``extends`` that will override the parent values of 75.
-
-Looks great! Now let's get these cards out to the playtesting table!
-
-At this point, we've got a very scalable design for our future iterations. Let's take side-trip and discuss why this design works.
-
-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 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:
-
-  * *Game data decisions*. How many of this card should be in the deck? What should this card be called? What should the cost of this card be?
-  * *Style Decisions*. Where should this icon be? How big should the font be? What color should we use?
-  * *Logic Decisions*. Can we build this to a PDF, too? How do we save this in black-and-white? Can we include a time stamp on each card? Can we just save one card this time so we can test quickly?
-
-With the Ruby+YAML+Spreadsheets design, we've separated these three kinds of questions into three areas:
-
-  * Game data is in a spreadsheet
-  * Styles are in YAML layout files
-  * Code is in Ruby
-
-When you work with this design, you'll probably find yourself spending a lot of time working on one of these files for a long time. That means this design is working.
-
-For example, you might be adjusting the exact location of an image by editing your layout file and re-running your code over and over again to make sure you get the exact x-y coordinates right. That's fine. You're not making game data decisions in that moment, so you shouldn't be presented with any of that stuff. This eases the cognitive complexity of what you're doing.
-
-The best way to preserve this design is to try to keep the Ruby code clean. As wonderful as Ruby is, it's the hardest of the three to edit. It is code, after all. So don't clutter it up with game data or style data - let it be the glue between your styles and your game.
-
-Ok, let's get back to this prototype.
-
-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>
-
-
-Method 2: Map title to file name
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-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::
-
-  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.

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

@@ -1,46 +0,0 @@
-The Squib Way pt 3: Workflows
-===============================
-
-.. warning::
-
-  Under construction
-
-As we mentioned at the end :doc:`/guides/getting-started/part_2_iconography`, we've pretty much got most of what we need to prototype a game through completion. From here on out, the :doc:`/dsl/index` will be your best resource for getting things done. Everything from here one out is optional, but useful.
-
-But, as you explore Squib's features and work away at your games, you'll pick up a few tricks and conventions to follow that makes your time easier. After years of developing games with Squib, here are some helpful ways of improving your workflow.
-
-Improving your workflow comes down to a few principles:
-
-  * **Automate what will be tedious**. There's a balance here. What do you anticipate will change about your game as you develop it? What do you anticipate will *not* change? If you automate *everything*, you will probably spend more time on automating than game development. If you don't automate anything, you'll be re-making every component whenever you make a game design change.
-  * **Focus on one thing only: visual, game, or build**. Cognitively, you'll have an easier time when you focus on one thing and one thing only. The more loose ends you need to keep in your head, the more mistakes you'll make.
-
-Additionally, improving your workflow can help you pivot to other tasks you might need for polishing your game later on, such as:
-
-  * Quickly building one card at a time to reduce the time between builds
-  * Maintaining a printer-friendly, black-and-white version of your game in tandem with a color version
-  * Building annotated figures for your rulebook
-  * Rolling back to older versions of your game
-
-Organizing Your Project
------------------------
-
-Most games involve build multiple decks. Initially, you might think to put all of your Ruby code inside one file. That can work, but it gets slow and cumbersome. Instead, I like to organize my code into separate source code files inside of a `src` directory.
-
-Keeping your artwork in its own folder will also make it easier for you to find what you need later on. Also, using `img_dir` parameter in the `config.yml` will let you switch the entire image directory over in one
-
-Using a Rakefile
-----------------
-
-
-
-* Setting up rake tasks
-* Advanced project layout: splitting out decks into different files
-* Testing individual files (build groups, ranges, id-lookup)
-* Marketing images (using output as images, dependency in Rakefile)
-* Rulebook figures (build groups, annotate after saving)
-* Switch from built-in layouts to your own layout
-* Launch what you need with Launchy
-* Auto-building with Guard
-* Maintaining color and black-and-white builds (build groups, multiple layout files). Changing build sessions within Guard
-* Configuring different things for each build
-* Git (save to json, tagging, rolling back, Gemfile.lock)

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

@@ -1,18 +0,0 @@
-The Squib Way pt 4: Ruby Power!
-===============================
-
-.. warning::
-
-  To be written.
-
-
-This part is about cataloging some powerful things you can do if you're willing to write some Ruby.
-
-* Modifying XML at runtime (e.g. convert to black-and-white from color)
-* Using Travis to build and then post to something like Dropbox
-* Scaling the size of text based on its contents
-* Advanced Array techniques: inject, transpose, map, join (use the pre-req example)
-* Building newlines yourself (i.e. with your own placeholder like "%n" in Your Last Heist)
-* Summarization card backs for Your Last Heist as an example
-* "Lacks" string for Your Last Heist
-* Rules doc written in Markdown

data/docs/guides/git.rst

@@ -1,14 +0,0 @@
-Squib + Git
-===========
-
-.. warning::
-
-  To be written
-
-
-Ideas:
-  * .gitignore
-  * Workflow
-  * Tracking binary data (show json method)
-  * Snippet about "what's changed"
-  * Releases via tags and versioning

data/docs/guides/guard.rst

@@ -1,84 +0,0 @@
-Autobuild with Guard
-====================
-
-.. warning::
-
-  Under construction - going to fold this into the Workflow guide. For now, you can see my samples. This is mostly just a brain dump.
-
-Throughout your prototyping process, you'll be making small adjustments and then examining the graphical output. Re-running your code can get tedious, because you're cognitively switching from one context to another, e.g. editing x-y coordinates to running your code.
-
-Ruby has a great tool for this: `Guard <https://github.com/guard/guard>`_. With Guard, you specify one configuration file (i.e. a ``Guardfile``), and then Guard will *watch* a set of files, then execute a *task*. There are many ways of executing a task, but the cleanest way is via a ``rake`` in a ``Rakefile``.
-
-Project layout
---------------
-
-Here's our project layout:
-
-.. code-block:: text
-
-  .
-  ├── config.yml
-  ├── Gemfile
-  ├── Guardfile
-  ├── img
-  │   └── robot-golem.svg
-  ├── layouts
-  │   ├── characters.yml
-  │   └── skills.yml
-  ├── Rakefile
-  └── src
-    ├── characters.rb
-    └── skills.rb
-
-Using Guard + Rake
-------------------
-
-Guard is a gem, just like Squib. When using Guard, I recommend also using Bundler. So your Gemfile will look like this.
-
-.. literalinclude:: ../../samples/project/Gemfile
-  :language: ruby
-  :linenos:
-
-And then your Rakefile might look something like this
-
-.. literalinclude:: ../../samples/project/Rakefile
-  :language: ruby
-  :linenos:
-
-To get our images directory set, and to turn on proress bars (which I recommend when working under Guard), you'll need a ``config.yml`` file that looks like this.
-
-.. literalinclude:: ../../samples/project/config.yml
-  :language: yaml
-  :linenos:
-
-Note that we are using ``load`` instead of ``require`` to run our code. In Ruby, ``require`` will only run our code once, because it's about loading a library. The ``load`` will run Ruby code no matter whether or not it's been loaded before. This doesn't usually matter, unless you're running under Guard.
-
-And then our Guardfile
-
-.. literalinclude:: ../../samples/project/Guardfile
-  :language: ruby
-  :linenos:
-
-
-So, let's say we're working on our Character deck. To run all this we can kick off our Guard with:
-
-.. code-block:: text
-
-  $ bundle exec guard -g characters
-  14:45:20 - INFO - Run 'gem install win32console' to use color on Windows
-  14:45:21 - INFO - Starting guard-rake characters
-  14:45:21 - INFO - running characters
-  Loading SVG(s) <===========================================> 100% Time: 00:00:00
-  Saving PNGs to _output/character__* <======================> 100% Time: 00:00:00
-  ]2;[running rake task: characters] watched files: []
-  [1] Characters guard(main)> ow watching at 'C:/Users/andy/code/squib/samples/project'
-
-Guard will do an initial build, then wait for file changes to be made. From here, once we edit and save anything related to characters - any Excel file, our ``characters.rb`` file, any YML file, etc, we'll rebuild our images.
-
-Guard can do much, much more. It opens up a debugging console based on `pry <http://pryrepl.org/>`_, which means if your code is broken you can test things out right there.
-
-Guard also supports all kinds of notifications too. By default it tends to beep, but you can also have visual bells and other notifications.
-
-To quit guard, type ``quit`` on their console. Or, you can do ``Ctrl+C`` to quit.
-
-Enjoy!

data/docs/guides/hello_world.rst

@@ -1,65 +0,0 @@
-Hello, World! Dissected
-=======================
-
-After seeing Squib's `landing page <http://squib.rocks>`_, your might find it helpful to dissect what's really going on in each line of code of a basic Squib snippet.
-
-.. code-block:: ruby
-   :linenos:
-
-   require 'squib'
-
-   Squib::Deck.new width: 825, height: 1125, cards: 2 do
-     background color: 'pink'
-     rect
-     text str: ['Hello', 'World!']
-     save_png prefix: 'hello_'
-   end
-
-Let’s dissect this:
-
-* Line 1: this code will bring in the Squib library for us to use. Keep this at the top.
-* Line 2: By convention, we put a blank line between our require statements and the rest of our code
-* Line 3: Define a new deck of cards. Just 2 cards. 825 pixels wide etc. Squib also supports :doc:`/units` if you prefer to specify something like ``'2.75in'``.
-* Line 4: Set the background to pink. Colors can be in various notations, and supports linear and radial graidents - see :doc:`/colors`.
-* Line 5: Draw a rectangle around the edge of each card. Note that this has no arguments, because :doc:`/parameters`. The defaults can be found in the DSL reference for the :doc:`/dsl/rect` method.
-* Line 6: Put some text in upper-left the corner of the card, using the default font, etc. See the :doc:`/dsl/text` DSL method for more options. The first card will have ``'Hello'`` and the second card will have ``'World'`` because :doc:`/arrays`.
-* Line 7: Save our card out to a png files called ``hello_00.png`` and ``hello_01.png`` saved in the ``_output`` folder.
-
-Dissection of "Even Bigger..."
-------------------------------
-
-On Squib's `landing page <http://squib.rocks>`_ we end with a pretty complex example. It's compact and designed to show how much you can get done with a little bit of code. Here's a dissection of that.
-
-.. code-block:: ruby
-   :linenos:
-
-   require 'squib'
-
-   Squib::Deck.new(cards: 4, layout: %w(hand.yml even-bigger.yml)) do
-     background color: '#230602'
-     deck = xlsx file: 'even-bigger.xlsx'
-     svg file: deck['Art'], layout: 'Art'
-
-     %w(Title Description Snark).each do |key|
-       text str: deck[key], layout: key
-     end
-
-     %w(Attack Defend Health).each do |key|
-       svg file: "#{key.downcase}.svg", layout: "#{key}Icon"
-       text str: deck[key], layout: key
-     end
-
-     save_png prefix: 'even_bigger_'
-     showcase file: 'showcase.png', fill_color: '#0000'
-     hand file: 'hand.png', trim: 37.5, trim_radius: 25, fill_color: '#0000'
-   end
-
-* Line 3: Make 4 cards. Use two layouts: the built-in hand.yml (see :doc:`/layouts`) and then our own layout. The layouts get merged, with our own `even-bigger.yml` overriding ``hand.yml`` whenever they collide.
-* Line 5: Read some data from an Excel file, which amounts to a column-based hash of arrays, so that each element of an array corresponds to a specific data point to a given card. For example, ``3`` in the ``'Attack'`` column will be put on the second card.
-* Line 6: Using the Excel data cell for the filename, we can customize a different icon for every card. But, every SVG in this command will be styled according to the ``Art`` entry in our layout (i.e. in ``even-bigger.yml``)
-* Line 8: Iterate over an array of strings, namely, ``'Title'``, ``'Description'``, and ``'Snark'``.
-* Line 9: Draw text for the (Title, Description, or Snark), using *their* styling rules in our layout.
-* Line 13: Using `Ruby String interpolation <https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#Interpolation>`_, lookup the appropriate icon (e.g. ``'attack.svg'``), converted to lowercase letters, and then using the Icon layout of that for styling (e.g. ``'AttackIcon'`` or ``'DefendIcon'``)
-* Line 17: Render every card to individual PNG files
-* Line 18: Render a "showcase" of cards, using a perspective-reflect effect. See :doc:`/dsl/showcase` method.
-* Line 19: Render a "hand" of cards (spread over a circle). See :doc:`/dsl/hand` method.