Espresso 3 beta is out!

Hooray! Espresso 3 is at last available as a public beta! I’ve been one of the few people using this version of the app for a while (yikes, is it years now?), and I think you’re going to love some of the new features. You’re probably going to dislike a lot of the rough edges, but for what it’s worth I’ve been using Espresso 3 as my primary editor for the past 4-6 months and haven’t run into any huge show-stoppers (note that I’ve been basically using it only to edit text, though; not so much with the server connections, since my recent work has been all git-managed for deployments).

In any case, the beta has practically no documentation included, so how about I introduce you to some of the new features you’ll find in Espresso 3?

Text Editing

LESS and SCSS, sitting in a tree

Probably my favorite feature in Espresso 3 (and one of the ones I had a big hand in developing) is support for LESS and SCSS. Just pop open a LESS or SCSS file and sigh in relief at the comprehensible syntax coloring. Give the CSS tools a spin and giggle as they actually work on nested rules.

“But,” I hear you say, “almost all editors these days support syntax coloring for LESS and SCSS! What’s so special about Espresso 3?” I’m so glad you asked, because it leads me to one of my other favorite features: Dynamo.

Try this:

  1. In Espresso 3, create a new empty project; mine’s called “Blow my mind”
  2. Add a new file in the project named index.html and give it the following contents:

    <html lang="en-US">
        <meta charset="UTF-8">
        <title>My excellent file</title>
        <link rel="stylesheet" href="css/styles.css" />
        <h1>Is this text red?</h1>
  3. Preview your file. The text is, sadly, not red.
  4. Add a new folder named css, then add a new file inside named styles.scss with the following contents:

    h1 {
        color: red;
  5. Now for the magic: rename the folder css to css.esdynamo. Wait for it…wait for it…
  6. Observe the fact that Espresso has created a folder called css with a file named styles.css inside; switch back to your preview and observe your lovely red text.
  7. Try changing the color of your header in styles.scss and watch what happens in your preview.

Welcome to Dynamo.

(Dynamo can actually do a lot more than just automatically render CSS pre-processors, but I’ll leave that for another day.)

Welcome home, text re-indentation

In CSSEdit, you could automatically re-indent your CSS. This was incredibly handy for working with “minified” CSS, or fixing a co-workers’ poor “style choices”.

Espresso 2 sadly never gained this ability, and in fact largely dictated a single style of CSS formatting.

In Espresso 3, text re-indentation is back, and it lives in the Text menu. Not only that, but you can specify a specific style and have that be used for re-indentation. Whoo hoo!

Note that this is one area that is probably undertested; there will be bugs here.

Tab it your way

One of the most common complaints directed at Espresso 2 came from people who disliked the vertical tabs of the Workspace. In Espresso 3, you can continue to use the Workspace just like you always have, or you can ditch it in favor of tabs along the top of the window: just click the arrow next to “Workspace” and select Show Tab Bar.

Quick Open and the new filter bar

Want to find a file whose name you know? The Quick Filter now lives at the bottom of the left sidebar.

Want to find a file whose name you mostly know? Try the new Quick Open feature, accessible with command shift O (that’s the letter “oh”) or via the “target” menu icon in the toolbar.

Additionally, if you want a little more context about the files in your Workspace, click the star icon in the filter field at the bottom right corner of the left sidebar. You’ll get a filtered look at your project files showing only items that are currently open in the Workspace/tabs.

Zen and the art of snippet maintenance

Snippets no longer live in a floating window! Huzzah! Instead, you can find your snippets in the “zen” toolbar item. Snippets themselves are largely unchanged (same syntax, although the editor now syntax colors them so it should be easier to see when a stray question mark is going to trigger a tab stop zone instead of outputting a PHP variable!), but there are two nice additions worth calling out:

  1. You can specify a language context for your snippets (so Javascript snippets only show up in Javascript, for instance)
  2. If you save a snippet to the “Favorites bar” it will show up in the toolbar next to the “zen” icon

No, you can’t sort your snippets into groups. Give that one a rest already, there’s like a million other more important things on Jan’s plate! ;-)

Navigating the Navigator

If you’ve used Espresso 2 for any length of time you probably know that the Navigator can be a real boon for finding things quickly, but gets less and less useful the more complicated your file becomes. Now you can click the “filter” icon in the upper right corner of the Navigator and filter things visually based on their names. Whoo!

Syncing files

In Espresso 2, servers were saved within the context of individual projects. So if you had a single server that hosted multiple websites, you had better keep the username and password handy, because you were going to be entering it a bunch.

Espresso 3 does away with this, and allows you to instead save server credentials globally, and associate specific paths to projects.

If that makes you excited, check the upper left corner of your window for a happy little cloud icon; this is “Clodette” (I hope Jan doesn’t get mad at me for sharing her codename), and she’s going to be your very good friend.

To get started, click Clodette and choose Connect To; this interface will allow you to quickly create a new connection, or connect to a previously-saved server for file browsing and after you are done configuring the connection, the server will open up in your Workspace alongside your files. This is the most basic method for connecting to a server from an Espresso 3 project, but the connection will not persist after you close it in your Workspace.

For the full meal deal, click Clodette and choose Servers + Settings. This will replace your project sidebar with three new sections: Sync, Places, and Sync Specific Folders. Adding a server connection to Sync or Places is roughly equivalent to adding a server to an Espresso 2 project, except explicitly tied to a Sync or Browse server action. The main difference is that instead of accessing your servers in a list within the left sidebar, you will access them from Clodette (which will add them to your Workspace).

Sync Specific Folders is where the really fun new stuff comes into play. From here, you can add a sync server that only operates on a single folder in your project (just click the folder icon next to the folder you want to sync). So for instance, if you are building your website out with Gulp or whatever, you can attach a sync server to your build folder (in Espresso 2, you would need a secondary project for that folder to sync it). Or you could sync your assets folder to a CDN server and your program logic to another. The possibilities are pretty wide-open.

Just like the other server configuration options, adding a server basically saves a bookmark that you can then open in your Workspace when you need to work with it actively.

And of course since what Espresso is saving is the server path that’s associated with your project (or project’s folder), you can easily use your server credentials across multiple projects without needing to re-enter them.


This is one of the buggier and more incomplete sections of the app, but it deserves mention. Espresso 3 now allows you to preview files either in Espresso, or in basically any other browser on your computer. Live reloading (and, although it’s not really functional yet, X-ray) come along for the ride regardless of where the preview is living.

No longer do you need to wonder why your swanky CSS3 is failing in weird ways; simply open it up in Chrome, Safari, Firefox, etc. and observe the behavior in a more modern rendering engine (Espresso is stuck with an older version of WebKit for technical reasons largely out of MacRabbit’s control).

But…what about my custom syntax coloring?

Older syntax themes are probably going to break with Espresso 3 (let’s be honest: a lot of them broke with Espresso 2). But fear not! For those of you with excellent taste in themes, Earthworm and Quiet Light are both up and running for Espresso 3, and I have additionally created a SCSS template for generating your own themes. You can find both here (the themes are included as examples with the template generator):

Will this make it easier to create themes for Espresso? Who knows! On the plus side, it doesn’t require you to know much of anything about the specific syntax zones being used, but I will admit that the massive number of possible SCSS variables you can use might be a bit confusing. Now that Espresso 3 is actually out and other people might be using this beast, I am hoping to come back to it and improve it in my spare time. Feedback and pull requests are also always welcome!


Before you ask, here’s what you’ll get from me: ¯\_(ツ)_/¯

Jan decided on Espresso 3’s new pricing scheme after I left MacRabbit, so you know as much as I do. I can say that Espresso 2’s pricing (and particularly it’s ridiculously lenient and dirt-cheap upgrade policy) was non-sustainable, though, so a pseudo-subscription makes a lot of sense from a business standpoint. I’m not too worried about it, frankly. One thing I learned working at MacRabbit is that Jan always, always has users in mind when making decisions for Espresso whether he’s making design decisions or figuring out upgrade and pricing policies.

So should I use Espresso 3?

Not that I’m incredibly biased or anything, but yes! At the very least, if the features I described above sound interesting, you should definitely test it out. Depending on what you rely on day-to-day, some of the rough or unfinished edges might prevent you from using it as your main editor until it’s a little more fleshed out and less “beta”, but there’s a lot to love about Espresso 3. In particular, one thing I didn’t mention is that Espresso 3 is a complete visual refresh for the editor and looks amazing. Seriously, Coda is eating its heart out, and I think I hear BBEdit crying softly in the corner right now.

And although I’m no longer affiliated officially with MacRabbit, feel free to ask me if you have any questions! I’m still hacking away at my custom Espresso plug-ins, and aside from Jan am arguably the person most familiar with the current state of Espresso. Rough edges and all, Espresso is still my absolute favorite editor for front-end development work (and just general happy state of mind while writing code). Sure, some of that is years worth of habit and lingering loyalty from working at MacRabbit, but you know what? Every good piece of software needs someone to proselytize it, and even in its current beta state Espresso 3 is a very good piece of software.

Don’t just take my word for it, though: try it yourself!

The tragic internal consistency of Steins;Gate

The first time I watched the anime Steins;Gate, I was unsure why so many people were raving about it. The first six episodes or so I mostly spent wondering why I should care about these characters, most of whom were incredibly off-putting (particularly the protagonist). Then the time travel aspects finally kicked in a bit, which grabbed my interest enough to keep me watching in hopes that the brilliance people were talking about would show up. And then about twelve episodes in the show kicked it up into high gear and I was on the edge of my seat right up until the last couple episodes.

However, those last few episodes really soured the show for me, because there seemed to be so many plot holes and inconsistencies. Additionally, I made the unfortunate choice to watch the additional OVA episode (basically an epilogue), and its horrific English voice acting, inappropriate tone (compared to the rest of the series), and the fact that its sole redeeming scene was basically ripped off from one of the best scenes in the season itself badly tainted my memories of Steins;Gate.

Despite that, recently the series was on sale, so I bought it (at a dollar an episode, watching it once was basically going to be worth the money) and boy did it ever improve on the second time around. The first six episodes weren’t bad at all, because I knew what we were working for and could savor some of the little details that I missed the first time around. The final twelve episodes were just as incredible as I remembered, and the emotional pay-off at the end hit even harder because I felt a much greater connection to the characters.

Not only that, but I did some thinking about the final events of the series and realized that far from being inconsistent, within their rather wonky time travel setup everything checked out perfectly. In point of fact, although the ending is incredibly hopeful, there appears to be a hidden tragedy years after the series completes, simply because of how closely they stuck to their time travel rules.

If you’ve seen Steins;Gate, feel free to keep reading; I’m going to pick apart the way that time travel is structured in the show, along with the final few events, to show both why it is internally consistent and why a tragedy lurks within Okabe Rintaro’s otherwise happy ending.

If you haven’t seen Steins;Gate, then begone! Go watch it and come back later. Seriously, I’m going to majorly spoil the series for you otherwise.

Spoilers to follow! Time travel in Steins;Gate

One of the weirdest aspects of Steins;Gate is its time travel, because while it masquerades as multiple world theory, it is effectively dealing with linear time. This is part of what threw me in my initial viewing; Steins;Gate’s “world lines” seemed to me to be multiple worlds, which makes the way the series ends in particular seem to be little more than hand-waving on the parts of the writers.

Classic time travel stories typically involve linear time. When traveling in linear time, time paradoxes are possible since there is only a single timeline. Anything that a time traveler does in the past either has to percolate up and effect the present, or has to be revealed to have already happened. From a story-telling perspective, the benefit of linear time is that the stakes are very high: if the protagonist goes back in time and kills their parents, they will cease to exist, for instance. The downside is that it is very easy to write yourself into a corner.

Recent time travel stories typically involve some form of multiple worlds. When dealing with multiple worlds, you actually have the opposite problem from linear time: going back in time doesn’t affect your personal past because the act of doing so causes you to enter an alternate world/dimension/timeline/etc. The story-telling benefit of this is that you can play around with past actions with virtually no consequences and without having to worry about time paradoxes because every action simply spawns a new world. The major downside is that if the characters give it any thought at all they will realize that they have no motivation to try and change the past (outside of potentially seeking a better world just for themselves) because each world exists on its own; if the protagonist has a tragic outcome, changing the past actually won’t matter because that tragic outcome will still exist.

Steins;Gate has a weird merger of these two approaches to time travel. Basically, changing anything major in the past results in a new world line, but the show very explicitly notes that the characters are “moving” to a new world line (and then “forget” everything that happened in the other timeline). That is, they are effectively participating in linear time, but the course of that linear time can be restructured after the fact. This works because Okabe Rintaro is given the ability to maintain an accurate memory of his personal linear progress through time regardless of how his consciousness moves around in time.

Wait, aren’t we short one Okabe Rintaro?

The biggest thing that bugged me for the final few episodes of Steins;Gate was that when Okabe physically goes back in time, there are only ever two versions of him running around (past Okabe, and time traveling Okabe). “Isn’t that a plot hole?” I asked myself. “He went back twice, so there should be three of him!”

However, what I didn’t realize initially is that when he goes back in time that second time, the world line has shifted behind the scenes.

Here’s the thing: for almost the entire show, we only see what happens for the Okabe who causes the world line to shift. He sends a D-mail to the past, and then his perspective gets wonky and next thing we know the world has changed around him. However, just prior to that second physical trip into the past, he receives a video file from his future self and from his perspective the world line remains stable. This is because it is his future self who experiences the world line changing; he’s the one who sent the video D-mail.

What happens is this:

Okabe Rintaro physically travels back in time and kills Makise Kurisu. When he comes back he is so stricken with grief and hopelessness that he refuses to go back in time again. However, over the course of the next fifteen years, he helps develop an actual, physical time machine. He additionally improves on the capabilities of his original D-mail to allow him to send video. And, in a desperate bid to change his life, he sends a video back, pleading with his past self to try and save Makise Kurisu a second time.

However, we the viewers don’t get to see all that, because we’re following the Okabe Rintaro who receives that D-mail video. The video spurs him to action that he did not originally take, which changes the world line. As a result, when he goes back in time the second time, there are only two Okabe Rintaros because the first trip occurred on a separate world line. His actions successfully save Makise Kurisu’s life, and the final credits end with the two of them reuniting coupled with hints that they will be able to rebuild their relationship.

Happily ever after…?

And now we come to the hidden tragedy within Steins;Gate. At the end of the series, the Okabe Rintaro we the viewers know and love has exactly 15 years to enjoy whatever sort of life he can form with Makise Kurisu, because at the end of that time his consciousness is going to disappear as if it had never been when the version of him that sent the D-mail video jumps world lines.

Do they end up marrying; maybe having kids? Hope he enjoys their childhood/early adolescence, because 15 years after the anime ends he’s going to forget their names and be introduced to them basically as a stranger.

The first time I saw it, I liked Steins;Gate but was disappointed that the writers discarded Makise Kurisu’s very emotional death in favor of a happily-ever-after that felt grafted on and played fast and loose with the time travel rules they themselves had come up with.

Having watched it again, though, I love Steins;Gate. Despite my initial impression, it’s one of the most internally-consistent time travel stories I’ve ever seen, and it somehow manages to not only deliver a happy ending, but also simultaneously delivers an ending that stays true to the theme of loss and sacrifice going hand in hand with trying to change the past.

Which is not to say that I don’t find the setup for time travel pretty ridiculous (the whole series relies on some serious suspension of disbelief, and there are admittedly some plot holes like the static-only video that’s sent to his past self transforming into an actual video), but since internal consistency is often what makes or breaks time travel stories I’m not going to complain too much.

Editing preference files in OS X 10.9 and 10.10

This is not a problem that most people will ever encounter, but ever since I upgraded to OS X 10.9 I’ve been having a terrible time with preference plist files (I typically need to edit these to test bugs in MacRabbit software). Prior to OS X Mavericks and Yosemite it was possible to edit a plist file, launch the application, and your changes would automatically be read in. Now, however, there’s some sort of system-wide caching system that makes it very difficult to work directly with plists.

If for whatever reason you need to modify a plist file, here’s how to do it:

  1. Copy the plist somewhere safe (like your Desktop)
  2. Pop open the Terminal and run this command (replacing com.macrabbit.Espresso with the name of the plist you are trying to edit:

    defaults delete com.macrabbit.Espresso
  3. Edit the copy of the plist that you made (I like to use PlistEdit Pro), then copy it back into your ~/Library/Preferences folder
  4. In Terminal, run this command:

    defaults read com.macrabbit.Espresso

And there you have it! Next time you open the app, your modified preferences will be available. Kind of a pain, but at least it’s still possible!

Hohokum, and the final three hidden eyes

My wife has been playing (and loving) Hohokum on our PS4; it’s a wonderfully quirky little game where you are a flying eyeball/snake/rainbow thing trying to find and free your fellow eyeball-snakes. Very unique artwork, some hilariously weird internal logic for some of the levels, and just generally lots of fun. We’d highly recommend it to anyone who enjoys games that aren’t focused on shooting, stabbing, or punching stuff.

One of the reasons she enjoyed the game is that there are eyeballs scattered throughout the levels that open up when you fly over them, and she’s a big fan of optional collectibles that force you to explore. However, having tracked down all but three of the eyeballs, she just about pulled out all of her hair trying to find the remaining ones. Sadly, the internet was completely without help to offer, so for several weeks Hohokum lay collecting virtual dust on the PS4 shelf.

This isn’t a walkthrough, but there are spoilers ahead! If you are having trouble finding the final three eyeballs in Hohokum, here’s your first hint:

They’re located in the original world (full of flying worm-things and pop-able “nuts”), where the one-eyed geezer is chalking down your progress opening eyeballs.

Not enough? Okay, how about this:

You can find the final three eyeballs behind three of the pop-able nuts.

“Arg!” I hear you cry. “But there’s about a million of those dang nuts to pop!” Aside from the fact that you might want to do it anyway (achievements come to those who are anal retentive, after all), don’t you enjoy the thrill of the chase? The sense of personal achievement that comes from digging through the haystack to find those final three needles? (Assuming, of course, that you didn’t give up in the floating logs level…wow was that one ever a pain in the butt.)


Yeah, my wife and I don’t either. Life’s too short. So here you go, the locations of the final three eyes (click for full size images):

Hohokum Eye #1   Hohokum Eye #2   Hohokum Eye #3

Enjoy your time with Hohokum!

Mexican hot chocolate chip cookies

One hot day a few summers back we wandered down to the local ice cream counter and discovered something wonderful: Mexican hot chocolate ice cream. Mmmmm.

Flash forward a year or two and my wife decided that she was going to recreate the awesomeness of their ice cream in cookie form. After several delicious tests to balance out the spices and get the technique right, she landed on a recipe that has quickly become a favorite of friends and family around the Beck household.

And now we’re sharing it with you!

Mexican hot chocolate chip cookie recipe

(Adapted from the Nestle Toll House Mint Chocolate Delights recipe)

  • 2 cups all-purpose flour
  • 2/3 cup cocoa powder (my wife prefers Hersey’s Special Dark)
  • 1 teaspoon baking soda
  • 1/2 teaspoon salt
  • 1 teaspoon cinnamon
  • rounded 1/8 teaspoon chili powder
  • 1 cup butter (2 sticks)
  • 2/3 cup granulated sugar
  • 2/3 cup packed brown sugar
  • 1 teaspoon vanilla extract
  • 2 large eggs
  • 10 ounce package semi-sweet chocolate chips
  • Small bowl of cinnamon sugar

Preheat oven to 325 F.

Combine dry ingredients, stirring well.

Cream butter and sugars for 3 minutes, then beat in vanilla and eggs.

Add dry ingredients in two batches. (Scrape the bottom of the mixer! This is a dry, stiff cookie batter.)

Stir in chocolate chips with a stiff spoon.

Roll into balls by hand, then roll each ball in cinnamon sugar, covering completely. Place on a cookie sheet with 1-2 inches in between each (these cookies don’t spread out much).

Bake 10-11 minutes.

Custom file extensions and Espresso 2

A fair number of people write into MacRabbit support asking how to add support for a custom file extension to Espresso (common requests being for LESS or SCSS mapped to CSS, various templating languages mapped to HTML or PHP, etc.). Unfortunately, a number of articles persist online instructing people to modify the built-in language plug-ins that live inside the Espresso application, which is not a good method to accomplish this particular task because you lose your changes when you update Espresso (additionally, mucking around with the internal plug-ins can sometimes lead to really weird behavior; for instance, messing up the built-in CSS support can have wide-ranging implications on Espresso’s syntax coloring for all languages).

Adding support for custom file extensions is extremely easy, but is unfortunately not something you can currently do through the GUI. Here’s how to go about it:

  1. Create a folder named something memorable. For instance, if you are mapping .less to CSS you might call it “LESS-Standin”. Or if you are feeling capricious, perhaps “Snickersnack”.
  2. Drag and drop your new folder on the Espresso Dock icon to create a temporary project window
  3. Within your new project window, create a new file named Languages.xml
  4. Add the following code to your Languages.xml file and save the file:

    <?xml version="1.0" encoding="UTF-8"?>
        <language id="com.yourdomain.less-standin" hidden="true">
            <name>LESS Standin</name>
  5. Convert the folder into a plug-in and install it (see below)

What you are doing is defining a new language for Espresso that references a pre-existing syntax. The things you will want to customize are the id attribute of the language element, the <root-zone> element, the <name> element, and your list of detectors.

You can find documentation for the available detectors in the Espresso plug-in development wiki, and here is a list of the most commonly-used root-zones that are included as of Espresso 2.1:

  • CSS: language-root.css
  • HTML: language-root.html
  • XML: language-root.xml
  • PHP: language-root.html.with-php
  • JavaScript: language-root.js
  • Markdown: language-root.markdown
  • Python: language-root.python
  • Ruby: language-root.ruby

If you wish for your language stand-in to show up in the View→Languages menu, remove the hidden="true" attribute from the language element. Also note that you can add multiple items within the <detectors> block in order to define multiple file extensions to map to the same language (so in the example above, you could add <extension>scss</extension> in order to map both LESS and SCSS to the built-in CSS parsing within the same plug-in).

Installing your new plug-in

You have a couple of ways you can install your new plug-in:

  1. Simply add a .sugar file extension to the folder you created, and double click to install it. This is a good option if you don’t expect to add support for other file extensions, since it’s straight forward and easy.
  2. Open up the Terminal and execute the following command (replacing the path to point to your new folder):

    cd ~/Library/Application\ Support/Espresso/Sugars
    ln -s PATH/TO/LESS-Standin LESS-Standin.sugar

The latter option will create a symbolic link pointing to your folder, which allows you to easily modify your Languages.xml file down the road.

After installing your plug-in with either of the methods above, relaunch Espresso and you should be good to go!

First impressions of Mojang’s Scrolls

When I was but a lad, my aunt introduced me to a little card game called Magic: The Gathering. And down that rabbit hole I went. Magic’s not perfect (and I haven’t purchased a card in years, at this point), but it certainly has provided me with years of entertainment and is a go-to game for some of the people I play games with to this day.

However, as the years went by, people I played Magic with tended to drift apart. College killed the hobby for me for a while, until I moved into a house with a few guys and discovered most of them had played when they were young. Then we graduated college, and now one of those guys is in Texas, another is just getting married, and I’ve got a baby on the way. All of which makes getting together for a game day every so slightly more difficult than when we could walk down the hall and say, “Hey, want to play a game of Magic?”

For years I have been trying one online TCG after another (or collectable card game, as some of them prefer to be called, since not all feature trading), but have been unable to find a fix worth replacing my Magic addiction with. So when I saw the announcements about Scrolls from the makers of Minecraft, I was highly intrigued. A game that isn’t pay-to-win? Tactical board game elements? Cards that transform into little animated characters? Sign me up!

Scrolls is now available for purchase in “public beta” form (whatever that means; frankly, once you start charging money you are providing a product no matter what you call it), and I have been playing it for the past few days to see if it will scratch my CCG itch.

Unfortunately, the short answer is “probably not so much.” While Scrolls is interesting, there are a number of flaws that are embedded deeply enough in the core gameplay that no amount of beta tweaking is likely to fix them.

(On the other hand, keep in mind that this is not really a review of Scrolls, because we are still very early in its lifecycle and Mojang has shown before that they are perfectly happy to charge for a very rough product, and then turn it into a completely different game by the time they proclaim it out of beta. So take these comments with a grain of salt, since they may well only apply to the game at the time of this writing.)

The curse of the starter deck

When you first launch Scrolls (after purchasing it), you will find yourself facing a choice in which starter deck to begin the game with. The choices are growth (lots of creatures), energy (machines and direct damage), or order (fewer creatures, more buffs). I chose growth, because who doesn’t like hordes of beasties?

Unfortunately, the growth starter deck at least is terrible (I can’t speak for the other, but strongly suspect them to be similar). It seems like Mojang opted for decks that provide a solid basis of cards representing the various things you can do with a given faction, rather than focusing the deck on a particular theme (the way I’m used to with Magic preconstructed decks). The good part about this is that once I accrue more cards (a lot more cards) I will have a good basis for deck-building faster.

The bad part about this is that the deck has so little internal synergy my first few games boiled down to more luck of the draw than anything else.

Take, for instance, this card (one of the few cards of which the growth starter deck contains the maximum three copies you could ever need):

Scrolls: Junkyard

At first glance, this appears to be a pretty neat card. It only costs one resource (the prominent top number). It has three defense, so provides a nice little barrier between your idols (the back row you have to protect) and your opponent’s low-power creatures. And every rat you play gets an extra health! Sounds like the perfect first-turn play, to me.

Except that the starter deck contains no rats. (At this point, I’m not sure if there are any rats in the initial batch of cards at all; I’ve never seen one in any of the cards I’ve purchased, or any of the bouts I’ve fought. I assume they must be out there, though, or why does this exist?)

Similarly, one of the “rare” cards included in the starter is a wolf who gains power based on how many other wolves you have in play, but because there are so many non-wolf cards it’s very difficult to get that synergy working correctly.

Taken alone, none of the cards in the starter are bad (I can see a use for most of them, if only I had the cards to support them), but taken together the whole thing plays poorly and with very little synergy.

Interesting decisions abound

Okay, so I was disappointed in the starter, but after playing at least a couple hours daily over the past week (and spending the 2,000 “gold” that the game provides you to start out), I was able to tweak the preconstructed deck just enough that it began to work a bit smoother (good-bye, Junkyard!). At this point, I started becoming familiar with the things that Scrolls does well. In particular, it provides a number of interesting decisions:

  • On a given turn, you can discard one of your cards in order to permanently increase the resources you have to spend on other cards. This leads to fun decisions in the early game (“Do I save this super-expensive, context-specific card in hopes that I can play it at the perfect time later, or transform it into a resource so I can play my low- and moderate-cost cards now?”)
  • On a given turn, you can discard one of your cards in order to draw two additional cards. However, this is mutually exclusive with sacrificing a card for resources.
  • After you get some creatures onto the battlefield, you have to decide where to move them. Most creatures have a cooldown value of at least two, which means the majority of them will only be attacking every other turn. Additionally, creatures can only move one square per turn. This can lead to some tricky tactical choices; do I spend two turns of movement to position my creature so my opponent can’t take it out on his next turn even if it results in a sub-optimal attack? Or do I chump block with it, and hope that something better comes up?
  • Anticipating your opponent. This is part and parcel of the tactical board play, but being able to predict what your opponent will want to attack is key to setting up your own attacks.
  • Timing (both of cards you play and movement) is very important. I have several times screwed myself up by moving a creature, sacrificing a card to draw two more, and discovering had I done that in the opposite order I would have had a far more optimal play.

All of this adds up to solving some of my least favorite parts of Magic: no lack of resources due to bad card draw, no turns where you’re just killing time hoping the one card you draw will make a difference, and no getting stuck with nothing in your hand and no way to refill it.

The flip side of tactical decisions

Unfortunately, there is a downside to all those tactical decisions that I love so much, and that is games that last quite a lot longer. Part of this is simply that you’ve got a lot of cards in your deck (50), so as long as one player doesn’t completely neglect to draw cards odds are good you’ll be able to pull something out to thwart at least some of your opponent’s schemes.

Additionally, because the game is so tactical, if one player gains a sufficient advantage in cards on the board, the end can be effectively decided long before the third idol falls. The card pool helps alleviate this somewhat by offering several things that can unexpectedly flip the game your way (creatures that attack the turn they come out, low amounts of distributed direct damage, etc.), but at least so far most of the games I have played have had a very clear winner by the mid-game and destroying the final one or two idols is mostly busywork as the winning player waits for their cooldowns to drop, which makes the game feel even longer.

Asynchronous play

Scrolls is fully asynchronous; on your opponent’s turn, you will spend your time passively watching whatever they decide to do. On yours, they’ll return the favor. This is extremely common in online CCGs, of course (playing Magic online takes forever, for instance, because both players have to be constantly opting out of responses whenever one player does something; in an asynchronous game this is a non-issue). However, it also reduces your investment in the game because if your opponent wants to take forever pondering the many decisions available to them, you might as well go out to coffee in the meantime.

Plus so far as I can tell, you can’t participate in anything except real-time matches, and the ability to participate in more leisurely games is about the only main upside to asynchronous play, so far as I am concerned.

Putting the “T” in TCG

While designing Scrolls, Mojang clearly was very interested in promoting a trading culture. There are basically three ways to get cards:

  1. Random singletons and packs (buying in a pack guarantees a seven commons, two uncommons, and one rare, whereas singletons are completely luck of the draw) for in-game gold. You get gold for playing matches, be they against other people, the AI, or the special “trials” that pit you against themed opponent AI (you can also “sell” cards back to the system, for a very small return)
  2. Six non-random cards that refresh weekly (two of each rarity) for either gold or “shards” (shards are purchased with actual money)
  3. Trading with other players

Of course you’ll notice that it is not possible to “pay to win” since the bulk of your cards will be purchased with gold (unless you can trade shards for gold with other players, which I have not investigated). This is good, because everyone is theoretically on an even playing field where your card collection is based more on how much time you’ve spent on the game than how much disposable income you have. But it is also bad, because it means that as the game gets older, it will be harder and harder for new players to collect a competitive set of cards without spending truly phenomenal amounts of time, either playing matches for gold or engaging in trades.

For me, this is a solid black mark against Scrolls because spending a bunch of time and energy trading has never been something I am interested in (not to mention the difficulty in figuring out what cards are worth, which requires up-to-date knowledge of the market and meta).

Idoling the time away

Coming away from my first brush with Scrolls, I get the feeling that this is a game that has been released at the wrong time in my life. I suspect that had it been release when I was younger, I would have loved it to pieces and spent far more time and money obsessing over it than I should. However, as I have grown older, my patience with games that demand huge chunks of my time in order to succeed has dwindled. I dislike arbitrary rarity schemes and the massive investment in time trading that they require to accrue a decent collection.

Oddly, although I find Scrolls’ theme to be one of the more unique fantasy worlds I’ve come across in a CCG recently, it ultimately leaves me flat. The idea that a bunch of people are wandering around with a giant collection of magic scrolls on their back just waiting to throw down is even less believable than things like Pokémon (which is saying something). Although the energy faction has some really quirky, interesting creatures, growth and order both feel very ho-hum to me (“wolves, and Vikings, and ducal liegemen…oh my?”).

In short, Scrolls demands a large chunk of my time, but the payout simply does not seem worth it. I will probably continue to try it on and off, and keep a general eye on its development, but at the moment it feels like something to idle away the time while I wait for Hearthstone or one of the other upcoming digital CCGs to fill the hole in my life left by Magic.