squib 0.12.0 → 0.13.0

data/docs/dsl/use_layout.rst

@@ -1,16 +0,0 @@
-use_layout
-==========
-
-Load a layout file and merge into the current set of layouts.
-
-Options
--------
-
-file
-  default: ``'layout.yml'``
-
-  The file or array of files to load. Treated exactly how :doc:`/dsl/deck` parses it.
-
-
-Examples
---------

data/docs/dsl/xlsx.rst

@@ -1,56 +0,0 @@
-xlsx
-====
-
-Pulls ExcelX data from .xlsx files into a hash of arrays keyed by the headers. First row is assumed to be the header row.
-
-The ``xlsx`` method is a member of ``Squib::Deck``, but it is also available outside of the Deck DSL with ``Squib.xlsx()``. This allows a construction like::
-
-  data = Squib.xlsx file: 'data.xlsx'
-  Squib::Deck.new(cards: data['name'].size) do
-  end
-
-Options
--------
-
-file
-  default: ``'deck.xlsx'``
-
-  the xlsx-formatted file to open. Opens relative to the current directory.
-
-sheet
-  default: ``0``
-
-  The zero-based index of the sheet from which to read.
-
-strip
-  default: ``true``
-
-  When ``true``, strips leading and trailing whitespace on values and headers
-
-explode
-  default: ``'qty'``
-
-  Quantity explosion will be applied to the column this name. For example, rows in the csv with a ``'qty'`` of 3 will be duplicated 3 times.
-
-Individual Pre-processing
--------------------------
-
-The ``xlsx`` method also takes in a block that will be executed for each cell in your data. This is useful for processing individual cells, like putting a dollar sign in front of dollars, or converting from a float to an integer. The value of the block will be what is assigned to that cell. For example::
-
-  resource_data = Squib.xlsx(file: 'sample.xlsx') do |header, value|
-    case header
-    when 'Cost'
-      "$#{value}k" # e.g. "3" becomes "$3k"
-    else
-      value # always return the original value if you didn't do anything to it
-    end
-  end
-
-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,126 +0,0 @@
-Squib + Game-Icons.net
-======================
-
-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.
-
-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/index.rst

@@ -1,5 +0,0 @@
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   part_*

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

@@ -1,145 +0,0 @@
-The Squib Way pt 0: Learning Ruby
-====================================
-
-This guide is for folks who are new to coding and/or Ruby. Feel free to skip it if you already have some coding experience.
-
-Not a Programmer?
------------------
-
-   `I'm not a programmer, but I want to use Squib. Can you make it easy for non-programmers?`
-
-   -- `Frequently Asked Question`
-
-If you want to use Squib, then you want to automate the graphics generation of a tabletop game in a data-driven way. You want to be able to change your mind about icons, illustrations, stats, and graphic design - then rebuild your game with a just a few keystrokes. Essentially, you want to give a list of instructions to the computer, and have it execute your bidding.
-
-If you want those things, then I have news for you. I think you *are* a programmer... who just needs to learn some coding. And maybe Squib will finally be your excuse!
-
-Squib is a Ruby library. To learn Squib, you will need to learn Ruby. There is no getting around that fact. Don't fight it, embrace it.
-
-Fortunately, Squib doesn't really require tons of Ruby-fu to get going. You can really just start from the examples and go from there. And I've done my best to keep to Ruby's own philosophy that programming in it should be a delight, not a chore.
-
-Doubly fortunately,
-
-  * Ruby is wonderfully rich in features and expressive in its syntax.
-  * Ruby has a vibrant, friendly community with people who love to help. I've always thought that Ruby people and board game people would be good friends if they spent more time together.
-  * Ruby is the language of choice for many new programmers, including many universities.
-  * Ruby is also "industrial strength", so it really can do just about anything you need it to.
-
-Plus, resources for learning how to code are ubiquitous on the Internet.
-
-In this article, we'll go over some topics that you will undoubtedly want to pick up if you're new to programming or just new to Ruby.
-
-What You DON'T Need To Know about Ruby for Squib
-------------------------------------------------
-
-Let's get a few things out of the way. When you are out there searching the interwebs for solutions to your problems, you will *not* need to learn anything about the following things:
-
-  * **Rails**. Ruby on Rails is a heavyweight framework for web development. It's awesome in its own way, but it's not relevant to learning Ruby as a language by itself. Squib is about scripting, and will never (NEVER!) be a web app.
-  * **Object-Oriented Programming**. While OO is very important for developing long-term, scalable applications, some of the philosophy around "Everything in Ruby is an object" can be confusing to newcomers. It's not super-important to grasp this concept for Squib. This means material about classes, modules, mixins, attributes, etc. are not really necessary for Squib scripts. (Contributing to Squib, that's another matter - we use OO a lot internally.)
-  * **Metaprogramming**. Such a cool thing in Ruby... don't worry about it for Squib. Metaprogramming is for people who literally sleep better at night knowing their designs are extensible for years of software development to come. You're just trying to make a game.
-
-What You Need to Know about Ruby for Squib
-------------------------------------------
-
-I won't give you an introduction to Ruby - other people do that quite nicely (see Resources at the bottom of this article). Instead, as you go through learning Ruby, you should pay special attention to the following:
-
-  * Comments
-  * Variables
-  * `require`
-  * What `do` and `end` mean
-  * Arrays, particularly since most of Squib's arguments are usually Arrays
-  * Strings and symbols
-  * String interpolation
-  * Hashes are important, especially for Excel or CSV importing
-  * Editing Yaml. Yaml is not Ruby *per se*, but it's a data format common in the Ruby community and Squib uses it in a couple of places (e.g. layouts and the configuration file)
-  * Methods are useful, but not immediately necessary, for most Squib scripts.
-
-If you are looking for some advanced Ruby-fu, these are useful to brush up on:
-
-  * ``Enumerable`` - everything you can do with iterating over an Array, for example
-  * ``map`` - convert one Array to another
-  * ``zip`` - combine two arrays in parallel
-  * ``inject`` - process one Enumerable and build up something else
-
-Find a good text editor
------------------------
-
-The text editor is a programmer's most sacred tool. It's where we live, and it's the tool we're most passionate (and dogmatic) about. My personal favorite editors are `SublimeText <http://www.sublimetext.com/3>`_ and `Atom <http://atom.io>`_. There are a bajillion others. The main things you'll need for editing Ruby code are:
-
-  * Line numbers. When you get an error, you'll need to know where to go.
-  * Monospace fonts. Keeping everything lined up is important, especially in keeping indentation.
-  * Syntax highlighting. You can catch all kinds of basic syntax mistakes with syntax highlighting. My personal favorite syntax highlighting theme is Monokai.
-  * Manage a directory of files. Not all text editors support this, but Sublime and Atom are particularly good for this (e.g. `Ctrl+P` can open anything!). Squib is more than just the deck.rb - you've got layout files, a config file, your instructions, a build file, and a bunch of other stuff. Your editor should be able to pull those up for you in a few keystrokes so you don't have to go all the way over to your mouse.
-
-There are a ton of other things that these editors will do for you. If you're just starting out, don't worry so much about customizing your editor just yet. Work with it for a while and get used to the defaults. After 30+ hours in the editor, only then should you consider installing plugins and customizing options to fit your preferences.
-
-Command line basics
--------------------
-
-Executing Ruby is usually  done through the command line. Depending on your operating system, you'll have a few options.
-
-  * On Macs, you've got the Terminal, which is essentially a Unix shell in Bash (Bourne-Again SHell). This has an amazing amount of customization possible with a long history in the Linux/Unix/BSD world.
-  * On Windows, there's the Command Prompt (Windows Key, `cmd`). It's a little janky, but it'll do. I've developed Squib primarily in Windows using the Command Prompt.
-  * If you're on Linux/BSD/etc, you undoubtedly know what the command line is.
-
-For example::
-
-  $ cd c:\game-prototypes
-  $ gem install squib
-  $ squib new tree-gnome-blasters
-  $ ruby deck.rb
-  $ rake
-  $ bundle install
-  $ gem up squib
-
-This might seem arcane at first, but the command line is the single most powerful and expressive tool in computing... if you know how to harness it.
-
-Edit-Run-Check.
----------------
-
-To me, the most important word in all of software development is *incremental*. When you're climbing up a mountain by yourself, do you wait to put in anchors until you reach the summit? No!! You anchor yourself along the way frequently so that when you fall, you don't fall very far.
-
-In programming, you need to be running your code often. Very often. In an expressive language like Ruby, you should be running your code every 60-90 seconds (seriously). Why? Because if you make a mistake, then you know that you made it in the last 60-90 seconds, and your problem is that much easier to solve. Solving one bug might take two minutes, but solving three bugs at once will take ~20 minutes (empirical studies have actually backed this up exponentiation effect).
-
-How much code can you write in 60-90 seconds? Maybe 1-5 lines, for fast typists. Think of it this way: the longer you go without running your code, the more debt you're accruing because it will take longer to fix all the bugs you haven't fixed yet.
-
-That means your code should be stable very often. You'll pick up little tricks here and there. For example, whenever you type a ``(``, you should immediately type a ``)`` afterward and edit in the middle (some text editors even do this for you). Likewise, after every ``do`` you should type ``end`` (that's a Ruby thing). There are many, many more. Tricks like that are all about reducing what you have to remember so that you can keep your code stable.
-
-With Squib, you'll be doing one other thing: checking your output. Make sure you have some specific cards to check constantly to make sure the card is coming out the way you want. The Squib method :doc:`/dsl/save_png` (or ones like it) should be one of the first methods you write when you make a new deck.
-
-As a result of all these, you'll have lots of windows open when working with Squib. You'll have a text editor to edit your source code, your spreadsheet (if you're working with one), a command line prompt, and a preview of your image files. It's a lot of windows, I know. That's why computer geeks usually have multiple monitors!
-
-So, just to recap: your edit-run-check cycle should be *very* short. Trust me on this one.
-
-
-Plan to Fail
-------------
-
-If you get to a point where you can't possibly figure out what's going on that means one thing.
-
-You're human.
-
-Everyone runs into bugs they can't fix. Everyone. Take a break. Put it down. Talk about it out loud. And then, of course, you can always :doc:`/help`.
-
-Ruby Learning Resources
------------------------
-
-Here are some of my favorite resources for getting started with Ruby. A lot of them assume you are also new to programming in general. They do cover material that isn't very relevant to Squib, but that's okay - learning is never wasted, only squandered.
-
-`CodeSchool's TryRuby <https://www.codeschool.com/courses/try-ruby>`_
-  This is one of my favorites. It's pretty basic but it walks you through the exercises interactively and makes good use of challenges.
-
-`RubyMonk.com <https://rubymonk.com/>`_
-  An interactive explanation through Ruby. Gets a bit philosophical, but hey, what else would you expect from a monk?
-
-`Pragmatic Programmer's Guide to Ruby (The PickAxe Book) <http://ruby-doc.com/docs/ProgrammingRuby/>`_
-  One of the best comprehensive resources out there for Ruby - available for free!
-
-`Ruby's Own Website: Getting Started <https://www.ruby-lang.org/en/documentation/quickstart/>`_
-  This will take you through the basics of programming in Ruby. It works mostly from the Interactive Ruby shell `irb`, which is pretty helpful for seeing how things work and what Ruby syntax looks like.
-
-`Why's Poignant Guide to Ruby <http://poignant.guide/>`_
-  No list of Ruby resources is complete without a reference to this, well, poignant guide to Ruby. Enjoy.
-
-`The Pragmatic Programmer <http://www.amazon.com/The-Pragmatic-Programmer-Journeyman-Master/dp/020161622X>`_
-  The best software development book ever written (in my opinion). If you are doing programming and you have one book on your shelf, this is it. Much of what inspired Squib came from this thinking.

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

@@ -1,217 +0,0 @@
-The Squib Way pt 1: Zero to Game
-=================================
-
-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.
-
-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
-----------------------
-
-Squib is all about being able to change your mind quickly. Change data, change layout, change artwork, change text. But where do we start? What do we work on first?
-
-The key to prototyping tabletop games is *playtesting*. At the table. With humans. Printed components. That means that we need to get our idea out of our brains and onto pieces of paper as fast as possible.
-
-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.
-
-
-Get Installed and Set Up
------------------------------
-The ordinary installation is like most Ruby gems::
-
-  $ gem install squib
-
-See :doc:`/install` for more details.
-
-This guide also assumes you've got some basic Ruby experience, and you've got your tools set up (i.e. text editor, command line, image preview, etc). See :doc:`part_0_learning_ruby` to see my recommendations.
-
-Our Idea: Familiar Fights
--------------------------
-Let's start with an idea for a game: Familiar Fights. Let's say we want to have players fight each other based on collecting cards that represent their familiars, each with different abilities. We'll have two factions: drones and humans. Each card will have some artwork in it, and some text describing their powers.
-
-First thing: the title. It stinks, I know. It's gonna change. So instead of naming the directory after our game and getting married to our bad idea, let's give our game a code name. I like to use animal names, so let's go with Arctic Lemming::
-
-  $ squib new arctic-lemming
-  $ cd arctic-lemming
-  $ ls
-  ABOUT.md	Gemfile		PNP NOTES.md	Rakefile	_output		config.yml	deck.rb		layout.yml
-
-Go ahead and put "Familiar Fights" as an idea for a title in the ``IDEAS.md`` file.
-
-If you're using Git or other version control, now's a good time to commit. See :doc:`/guides/git`.
-
-Data or Layout?
----------------
-
-From a prototyping standpoint, we really have two directions we can work from:
-
-  * Laying out an example card
-  * Working on the deck data
-
-There's no wrong direction here - we'll need to do both to get our idea onto the playtesting table. Go where your inspiration guides you. For this example, let's say I've put together ideas for four cards. Here's the data:
-
-======  =======  ===============================
-name    faction  power
-======  =======  ===============================
-Ninja   human    Use the power of another player
-Pirate  human    Steal 1 card from another player
-Zombie  drone    Take a card from the discard pile
-Robot   drone    Draw two cards
-======  =======  ===============================
-
-If you're a spreadsheet person, go ahead and put this into Excel (in the above format). Or, if you want to be plaintext-friendly, put it into a comma-separated format (CSV). 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="data.csv"></code>
-
-Initial Card Layout
------------------------------
-
-Ok let's get into some code now. Here's an "Hello, World" code snippet
-
-.. 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="01_hello.rb"></code>
-
-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 1 card for now
-  * Line 4: Set the background to pink. Colors can be in various notations - see :doc:`/colors`.
-  * Line 5: Draw a rectangle around the edge of the deck. Note that this has no arguments, because :doc:`/parameters`.
-  * Line 6: Put some text in upper-left the corner of the card.
-  * Line 7: Save our card out to a png file called ``card_00.png``. Ordinarily, this will be saved to ``_output/card_00.png``, but in our examples we'll be saving to the current directory (because this documentation has its examples as GitHub gists and gists don't have folders - I do not recommend having ``dir: '.'`` in your code)
-
-By the way, this is what's created:
-
-.. raw:: html
-
-  <img src="../../intro/part1_00_expected.png" width=250>
-
-Now let's incrementally convert the above snippet into just one of our cards. Let's just focus on one card for now. Later we'll hook it up to our CSV and apply that to all of our cards.
-
-You may have seen in some examples that we can just put in x-y coordinates into our DSL method calls (e.g. ``text x: 0, y: 100``). That's great for customizing our work later, but we want to get this to the table quickly. Instead, let's make use of Squib's feature (see :doc:`/layouts`).
-
-Layouts are a way of specifying some of your arguments in one place - a layout file. The ``squib new`` command created our own ``layout.yml`` file, but we can also use one of Squib's built-in layout files. Since we just need a title, artwork, and description, we can just use ``economy.yml`` (inspired by a popular deck builder that currently has *dominion* over the genre). Here's how that looks:
-
-.. 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="02_onecard.rb"></code>
-  <code data-gist-id="d2bb2eb028b27cf1dace"
-        data-gist-file="02_onecard_rb.png"
-        class=code_img
-        ></code>
-
-
-There are a few key decisions I've made here:
-
-  * **Black-and-white**. We're now only using black or white so that we can be printer-friendly.
-  * **Safe and Cut**. We added two rectangles for guides based on the poker card template from `TheGameCrafter.com <http://www.thegamecrafter.com>`_. This is important to do now and not later. In most print-on-demand templates, we have a 1/8-inch border that is larger than what is to be used, and will be cut down (called a *bleed*). Rather than have to change all our coordinates later, let's build that right into our prototype. Squib can trim around these bleeds for things like :doc:`/dsl/showcase`, :doc:`/dsl/hand`, :doc:`/dsl/save_sheet`, :doc:`/dsl/save_png`, and :doc:`/dsl/save_pdf`. See :doc:`/bleed`.
-  * **Title**. We added a title based on our data.
-  * **layout: 'foo'**. Each command references a "layout" rule. These can be seen in our layout file, which is a built-in layout called ``economy.yml`` (see `ours on GitHub <https://github.com/andymeneely/squib/blob/master/lib/squib/layouts/economy.yml>`_ ). Later on, we can define our own layout rules in our own file, but for now we just want to get our work done as fast as possible and make use of the stock layout. See :doc:`/layouts`.
-
-Multiple Cards
---------------
-Ok now we've got a basic card. But we only have one. The real power of Squib is the ability to customize things *per card*. So if we, say, want to have two different titles on two different cards, our `text` call will look like this::
-
-  text str: ['Zombie', 'Robot'], layout: 'title'
-
-When Squib gets this, it will:
-
-  * See that the ``str:`` option has an array, and put ``'Zombie'`` on the first card and ``'Robot'`` on the second.
-  * See that the ``layout:`` option is NOT an array - so it will use the same one for every card.
-
-So technically, these two lines are equivalent::
-
-  text str: ['Zombie', 'Robot'], layout: 'title'
-  text str: ['Zombie', 'Robot'], layout: ['title','title']
-
-Ok back to the game. We COULD just put our data into literal arrays. But that's considered bad programming practice (called *hardcoding*, where you put data  directly into your code). Instead, let's make use of our CSV data file.
-
-What the ``csv`` command does here is read in our file and create a hash of arrays. Each array is a column in the table, and the header to the colum is the key to the hash. To see this in action, check it out on Ruby's interactive shell (``irb``)::
-
-  $ irb
-  2.1.2 :001 > require 'squib'
-   => true
-  2.1.2 :002 > Squib.csv file: 'data.csv'
-   => {"name"=>["Ninja", "Pirate", "Zombie", "Robot"], "class"=>["human", "human", "drone", "drone"], "power"=>["Use the power of another player", "Steal 1 card from another player", "Take a card from the discard pile", "Draw two cards"]}
-
-So, we COULD do this::
-
-  require 'squib'
-
-  Squib::Deck.new cards: 4, layout: 'economy.yml' do
-    data = csv file: 'data.csv'
-    #rest of our code
-  end
-
-**BUT!** What if we change the number of total cards in the deck? We won't always have 4 cards (i.e. the number 4 is hardcoded). Instead, let's read in the data outside of our ``Squib::Deck.new`` and then create the deck size based on that::
-
-  require 'squib'
-
-  data = Squib.csv file: 'data.csv'
-
-  Squib::Deck.new cards: data['name'].size, layout: 'economy.yml' do
-    #rest of our code
-  end
-
-So now we've got our data, let's replace all of our other hardcoded data from before with their corresponding arrays:
-
-.. raw:: html
-
-  <code data-gist-id="d2bb2eb028b27cf1dace" data-gist-file="03_csv.rb"></code>
-  <code data-gist-id="d2bb2eb028b27cf1dace" data-gist-file="03_csv_rb00.png"
-        class=code_img ></code>
-  <code data-gist-id="d2bb2eb028b27cf1dace" data-gist-file="03_csv_rb01.png"
-        class=code_img ></code>
-  <code data-gist-id="d2bb2eb028b27cf1dace" data-gist-file="03_csv_rb02.png"
-        class=code_img ></code>
-  <code data-gist-id="d2bb2eb028b27cf1dace" data-gist-file="03_csv_rb03.png"
-        class=code_img ></code>
-
-Awesome! Now we've got our all of our cards prototyped out. Let's add two more calls before we bring this to the table:
-
-  * ``save_pdf`` that stitches our images out to pdf
-  * A version number, based on today's date
-
-.. raw:: html
-
-  <code data-gist-id="d2bb2eb028b27cf1dace" data-gist-file="04_save_pdf.rb">
-  </code>
-
-The file ``_output/output.pdf`` gets created now. Note that we *don't* want to print out the bleed area, as that is for the printing process, so we add a 1/8-inch trim (Squib defaults to 300ppi, so 300/8=37.5). The ``save_pdf`` defaults to 8.5x11 piece of landscape paper, and arranges the cards in rows - ready for you to print out and play!
-
-If you're working with version control, I recommend committing multiple times throughout this process. At this stage, I recommend creating a tag when you are ready to print something out so you know what version precisely you printed out.
-
-To the table!
--------------
-
-Squib's job is done, for at least this prototype anyway. Now let's print this sheet out and make some cards!
-
-My recommended approach is to get the following:
-
-  * A pack of standard sized sleeves, 2.5"x3.5"
-  * Some cardstock to give the cards some spring
-  * A paper trimmer, rotary cutter, knife+steel ruler - some way to cut your cards quickly.
-
-Print your cards out on regular office paper. Cut them along the trim lines. Also, cut your cardstock (maybe a tad smaller than 2.5x3.5) and sleeve them. I will often color-code my cardstock backs in prototypes so I can easily tell them apart. Put the cards into the sleeves. You've got your deck!
-
-Now the most important part: play it. When you think of a rule change or card clarification, just pull the paper out of the sleeve and write on the card. These card print-outs are short-lived anyway.
-
-When you playtest, take copious notes. If you want, you can keep those notes in the PLAYTESTING.md file.
-
-Next up...
------------------------------
-
-We've got a long way to go on our game. We need artwork, iconography, more data, and more cards. We have a lot of directions we could go from here, so in our next guide we'll start looking at a variety of strategies. We'll also look at ways we can keep our code clean and simple so that we're not afraid to change things later on.