We also wrote a few clients (ncurses, android, flash), most of them remained unfinished/unreleased, including the server, unfortunately. I meant to put it on GitHub but still hesitating since it would only be for educational purpose and no real interest in pursuing the project much further.
The repo is below, he added disclaimers that it's rough code and was enough to help him make some useful decisions mainly around game length and balance as he developed his game.
For what it's worth, I've occasionally used a little LaTeX framework derived from  to create fairly high-quality prototype cards. Perhaps a LaTeX or PS output from Sqiub would be a useful extension.
From a quick skim though, I think I'll be giving Squib a try the next time I want to do something like this.
PS: If you are looking to promote Squib, as might already be obvious to you, I'd recommend /r/boardgamedesign  and somewhere (I'm not sure where) on BoardGameGeek . The latter might be especially interested as many people seem to create custom "fan decks" for existing board games. For example, the game Love Letter is frequently re-skinned or re-themed as seen at .
There's also http://paperize.io/prototypes which has recently opened up for a beta testing phase.
I haven't had a chance to try it out but it looks great. Apparently it allows you to build board game mockups, and then play them locally or online. Useful for prototyping gameplay without having to print stuff, or alternatively you can also try games out before buying them.
So I thought that this project can be used as a motivator to teach kids programming :) because it's like look kids, with this simple code, you can generate these awesome cards, isn't it great?
Maybe a DSL for describing simple 3D printable stuff would be an option if a printer is available.
Other physical alternative is, quite obviously, Arduino. I have no experience teaching kids but I think that it would be a really solid option too given they implement something useful (to some extent), and that's a really important point.
I mean a blinking LED is cool for the first time but then you just forget about it. But for playing cards, or 3D printed stuff, it's something you can actually use it and you can keep improving it, driving more learning.
Given the adoption of Arduino, I'd be surprised if no one has developed a solid course for kids yet.
- Data driven
- High-quality output
- Raster and vector output
What I don't like:
- Complicated to set up (install Ruby, install multiple dependencies, compile code). This will scare away many potential users.
- Complicated to use (edit text files and run command line scripts). While I like this workflow personally, I feel this will again scare away some people.
- There's already many generic tools where you can write scripts to produce images from input data. Maybe you could explain why your tool is better suited for designing cards, given how complicated it is?
I also wanted an open source alternative to nanDeck. I love nanDeck, and Andrea Nini has been amazingly responsive at fixing bugs quickly, and at pushing out new features frequently. But open source projects (if done right) build more of the user-developer community that I'm looking for.
Regarding being complicated. Personally, I made Squib to match the way I think. Doing rapid prototyping on card games is both complicated tedious no matter which way you slice it. Squib helps with the tedious part. Ruby provides so much to take complex tasks and condense them to readable code - I wanted to leverage that for a very specific task.
Yes, I know some people are scared away by the fact that it's programming. Or the fact that it's Ruby with some native dependencies. But (and this I know from my day job as a software engineering professor) Ruby is among the easiest programming languages to learn. Already, I've seen some folks over at BoardGameGeek enthusiastically pick up Ruby and learn it just for Squib (http://www.boardgamegeek.com/article/19640981). That's awesome and already more than I had hoped for.
Consider a hypothetical web application (no setup) where you write the same Ruby code and get a live preview (no need to explain windows users what a command line is) - this would take lots of work and money, but would probably be more popular.
Look also from the perspective of a person who is looking for a card design tool, is not emotionally attached to your project, and does not prefer Ruby over other languages. For these people, you compete against solutions like Tikz or Processing or some Python script, which are also capable of defining the content and layout of the cards separately. That's why I thought it might be a good idea to mention some amazing advantage of your tool in its short description.
If you want to create a community around your project, how about opening a gallery with examples, like the one the Tikz project has (http://www.texample.net/tikz/examples/all/)?
I'm mostly interested in rules based systems and AI and my research was leaning towards creating a DSL for describing players' strategy. I started out doing it in Prolog as an internal DSL but switched to ANTLR and changed it to an external DSL.
Ruby is a pretty great choice which I considered before moving to ANTLR.
Edit: As this is geared more towards creating physical prototypes you should post this on boardgamegeek if you haven't already.
I'm trying to do this in an ad hoc way on my own games, but progress is slow :(
Writing one from scratch is also fun and instructive as a programming exercise. A classic Input->Process->Outout problem, so many ways to approach it, huge scope for elegant engineering and, once you are done, a really great tool for your specific needs.
A larger percentage of the developers I know have their static site generators so I completely agree.
I still like to implement my own ideas, especially in fun languages like Erlang and Perl. I'm glad I can program, because personal programming in the small is fertile ground and tremendously useful. For starters, this entire site is generated by 269 lines of commented Perl, including the archives and the atom feed (and those 269 lines also include some HTML templates). Why? Because it was pleasant and easy, and I don't have to fight with the formatting and configuration issues of other software. Writing concise to-the-purpose solutions is a primary reason for programming in the twenty-first century.
Pretty neat regardless.
It's a web app, not a code library, but we're solving similar problems. We love Squib though, keep up the good work!