Posts Tagged ‘sanctuary’

A crash course on publishing to Lulu for $0

Wednesday, August 4th, 2010

The budget for the Sanctuary 17 manual, like pretty much everything we do, was $0. It took some adventuring to get the finished product we did, and I didn’t find many great guides out there with good advice. So here are some lessons I learned, in hopes that it saves someone else some time, too.

Scribus is pretty good, but only if you use the beta. Scribus is basically your main choice for free desktop publishing, unless I guess you happened to get Microsoft Publisher or something similar preinstalled on your computer. (And you shouldn’t want to use MS Publisher if you are a good-hearted person, anyway.) I normally pick stable versions of open-source stuff because I don’t feel like troubleshooting weird and/or known bugs. But in Scribus’s case, you get a better interface out of the beta, and — no joke — the ability to use the same master page for single-digit and double-digit page numbers. Yes, you read that correctly. In the stable version I was using, you had to create a separate master page once you hit page 10. I nearly did a spit take when I learned this.

Apart from quibbles like that, Scribus is a decent tool. The most complicated thing I needed it to do, wrap text around an arbitrary shape, was simple to accomplish once I found the right documentation. I have experience with Quark XPress and InDesign, so the only thing that seemed weird to me was that it assumes there is always a selected page. In Quark and InDesign, you can only select text blocks or images or what-have-you, not a page per se. This had some weird side effects at first, but once I figured out what was going on, it actually seemed a little more reliable in operation. i.e. it’s much clearer when you cut an item and then hit Paste where it will show up.

The main Scribus keys to learn are F2, which brings up the properties inspector which lets you do pretty much everything, and F6, which opens the layers panel. Control-T, oddly enough, opens a story editor on a text block — I was used to inDesign’s Control-Y. Incidentally, Scribus really wants you to use the story editor. It has an edit-in-place mode, but at least for me, it runs very sluggishly.

The main thing I found that Scribus sucks at is hyphenation. You want to hyphenate your text if you justify it. Trust me. Unfortunately Scribus doesn’t know that much about hyphenation, as it would a) hyphenate a single letter, as in “a-postrophe,” and b) hyphenate two lines in a row. Both are typographical no-nos (see: 1, 2) and make reading awkward. I don’t really blame Scribus for its failings here — proper hyphenation is an unsexy black art — but it was a little disappointing to have to adjust my layout to deal with this shortcoming.

Flickr Creative Commons Search is a great tool. Again, no budget for a real cover image. Flickr’s advanced search has an option to find photos whose creators allow to be adapted for commercial purposes. I lucked into this really fantastic photo of a salt mine — the lighting is incredible and the emplacements look almost like a real-life embodiment of our pixelly room layouts.

Likewise Font Squirrel. There are a ton of craptastic free font sites out there, but Font Squirrel is the only one I’ve seen out there that doesn’t have annoying ads or an annoying interface — and, on top of that, seems to avoid the shovelware fonts that plague most sites.

Lulu and CafePress appear to be the main choices for on-demand printing right now. This is the area where I think I still have a lot to learn, but CafePress and Lulu seemed to be the best way to not worry about fulfillment at all (i.e. actually mailing out printed copies, dealing with returns). We went with Lulu because we wanted to do a full-color manual. CafePress only lets you have color on the cover, not on any of the interior pages.

Either way, your choices as far as page size go are fairly limited — their main use case is self-published novels, so the sizes run fairly large. My dreams of having a NES-style pocket manual were totally dashed. We ended up going with a trade paperback size, which was not that freakishly big, actually. Lulu appears to have some small page sizes if you look at their poetry book options, but let’s be honest: whatever it is we are up to on this web site, it’s pretty far from poetry. That, and the only way it appears you’re able to get to that small paper size is to use their poetry book wizard, which not only a somewhat soul-deadening concept, but also doesn’t let you do your own layout.

The rule of four still applies. That is, your publication still needs to have a page count that’s a multiple of four because of how printing works. The gotcha I ran into was that I counted the front and back covers, but they are printed in a totally separate process, so the test run of the manual had two blank pages stuck to its end. (Lulu does not warn you about this, by the way.) So I ended up creating a 14-page Scribus document, saving the covers as PNG at 300 dpi, and outputting the interior pages to PDF. This shift also had the somewhat annoying side effect of having to reset my master page mappings, since my even pages were now on the left side and odd pages on the right.

Overprinting is only for the cover. Our original design for the manual had a subtle texture background for all the interior pages. Unfortunately, Lulu’s printing process is not that exact. Sometimes the background ran all the way to the edge of the page; other times, it stopped short and left an unsightly plain white edge. I ended up having to ax the background texture. On the cover, however, overprinting worked great.

Colors gotta get corrected… somehow. Computer monitors create colors by mixing red, green, and blue bits together in an additive process; the more that a color component is added, the lighter the resulting color becomes. Printing works the opposite way, since it uses chemical inks, not light beams. Professionals deal with the difference by making their monitor imitate print output; however, I couldn’t find a color profile for Lulu. So… guesswork time. In the end, their printing came out pretty close to what I had done onscreen, though the gameplay screenshots were kind of a bitch to work with, since the game is so dark overall. Because the cover is a big mass of black, I also needed to bump up the subtitle’s size, because the black ink was smearing a little.

You’ll need a proof. Well, duh. All kinds of problems became manifest as soon as I held an actual copy in my hand that were not obvious while grappling with a PDF.

It was an interesting little trip back into printland, all in all — regardless of how well it does, I’m looking forward to doing this again with our next project.

Why sell a paper manual for a Web game?

Monday, August 2nd, 2010

A very pertinent question. I admit it is a total anachronism– but I think it’s also an interesting experiment, too. My thought process began when we ran MochiAds during Where We Remain‘s load sequence. We had a really good experience using Mochi. Their API is pretty much plug-and-play, and the user interface for submitting games and checking up on revenue is very nice. But the money we were seeing out of Mochi was pretty underwhelming, perhaps because the ads were a bit… mistargeted. As Toups pointed out on the Select Button forums, “why did my browser start talking to me about dieting when I clicked the link.” I certainly saw more than my fair share of Clorox ads while testing things out, and I don’t think I have ever had a serious thought in my life about laundry detergent. Our CPM, the amount of money we got for every thousand impressions, was embarrassingly low. And on top of that, because we only had an ad-supported version on our own site, our number of impressions was pretty low, too.

So far as I know, there are two ways to increase your ad revenue: show more ads or increase your CPM. The latter was out of our control — I’m curious if there are actually things Flash games can do in that regard when they’re using a third-party ad network. So that left showing more ads. It was either dump our games into the wild world of Flash game portals to get more overall views, add more ads to our games, or both. I’ve already talked about my feelings about Flash portals elsewhere, and adding more ads seemed so, um, adversarial. Squeezing more cents out of people more or less against their will. I mean, why else would an ad blocker be the top extension in Google’s and Mozilla’s galleries?

Then the question becomes, how can you try to make money in a less annoying fashion? Rob Fearon asks people to pay what they want — once. Any donation gets you all of his games. Cactus put ten copies of Norrland up for auction; once they’re sold, he will release it for free online. Both these seem like interesting ways to go about the problem, though I feel weird about locking up my games entirely and I don’t think we’re famous enough to pull off an eBay auction.

So… donations, maybe? I have to admit, I don’t think I have ever just straight up donated money to anyone but a charity on the Internet. There’s always a dollars-for-stuff exchange. And Joel and I both love manuals, endangered species that they are. It was a fun project to put the Sanctuary 17 manual together, one I like to imagine we would do even if we weren’t putting it up for sale. I realize 12 pages for $10 feels like a strange economic proposition, but that’s not really the point. (And if we could have made it pay-what-you-want, we would have — but Lulu doesn’t offer that option.) We’d like it to be a way for, if you like our games, a way for you to support us and get something nice back.

If anything, I think that’s where we haven’t done things quite as successfully as we would want — I think people are seeing a pricetag and looking at it solely as a value proposition.

Oh, bonus question: why not offer a PDF version then? Because DRM sucks and in particular, PDF DRM is trivial to crack, and you wouldn’t even need a torrent to share the file– you could just email it. Why didn’t we throw the entire PDF up for free? That was a judgment call, and I think there are good arguments on both sides.

Later this week I’ll try to write up some notes for people who want to try out on-demand publishing, and in particular Lulu. There were a couple gotchas along the way.

The Cutting Room Floor

Wednesday, July 28th, 2010

As I mentioned in my last post, Sanctuary 17 underwent a lot of changes on the way to becoming a finished product.  As you might expect, that also means that a lot of things that were once in the design ended up bowing out along the way.  I thought it might be fun to take a look at some of the elements that just didn’t make the final cut, because I’m the kind of person who would find that fun.

Development Points: I touched on these briefly in the previous post, but one of the original concepts had the player bringing back energy to the central bunker to help improve the lives of the survivors.  Every time the player would bring back a full haul of energy, a certain number of hidden “development points” would be added, and as different point thresholds were hit, improvements would take place to the bunker.  Many of these consisted of the playing being given new equipment, which was the only way to acquire it at the time.  But as things got better and better for the survivors, they would actually start to expand into the surrounding maze, securing areas for you to create zones of safe passage.

The problem here, as I said before, was that this encouraged an awful lot of energy grinding, and anchored the player too closely with the bunker.  Plus, as the story evolved as well, it just didn’t fit thematically.

The MCP: There was, at one point, an additional ending to the current three.  In this branch of the storyline, the player is able to locate the robot “nest” in their area, and tackles the robots at their source.  Facing down with the Master Control Program (as we called it), if the player is able to destroy it and its army of robot defenders, then the humans are free to continue living underground, unharassed.

Unfortunately, the whole sequence felt out of step with the rest of the game; it was far more action intensive, and just didn’t feel quite like it jived.  Thus… cut.

The Conversion Gun: This is perhaps the element that hung around the longest before being dropped, and would have had a very large impact on gameplay.  In addition to the basic pistol and railgun that made it to the final release, there was a third weapon called the conversion gun.  Unlike the other two, the conversion gun didn’t destroy robots; it (as you probably guessed) turned them into allies.  With a very short range, and requiring three hits to fully convert a target, it was a tricky weapon to use.  Once converted, however, friendly robots would roam the maze, targeting enemy robots and creatures and just generally absorbing bullets for you.

While the conversion gun was certainly a lot of fun, it was not without problems.  First and foremost, there were the requisite technical issues; more importantly, though, was how it effected gameplay.  A skilled player armed with the conversion gun could have a literal army of robots roaming around the maze, blasting everything in sight (including, occasionally, the player).  In the end, in just proved to be too unbalancing both in energy usage and usefulness to the player, and thus it made a graceful exit.