Twofold Secret

Sometimes cliches really are true.

When we first started working with Flixel, it was right after I tried writing a Zelda-like game entirely in JavaScript. (I called it Zelda’s Maze and almost all of the ideas in it showed up in Where We Remain.) The experiment kinda sorta worked. I got OK framerates in Chrome, but Firefox was all over the place and IE didn’t even support the <canvas> tag back then, so the results were mixed at best. The landscape is a bit different now — there are projects out there like Akihabara — but then, it seemed like the clear choice for browser-based game creation was Flixel. (Flashpunk didn’t exist back then, either!)

Switching to Flixel meant not only learning a new language, ActionScript, but also a new environment, the Flash runtime. ActionScript is basically a stronger-typed JavaScript, so it didn’t take that long to get comfortable with it. The Flash runtime, though, was a whole different story. Flixel is full-featured enough that you don’t need to learn anything at all about how the pixels actually get onscreen and the sounds get played — so we didn’t worry about those details with Where We Remain. As a result, the game hewed very closely to what was possible in Flixel then. There were a number of things we ended up cutting out because I couldn’t figure out how to make them work. The shoes everyone hated, for example, were originally going to allow you to either move through the trees on the map or maybe even through the mountain tiles, albeit at a slower speed. But at the time I couldn’t figure out how to selectively collide the map with the player. Joel was also keen on animating the map, especially for the water, but that was also beyond me.

Looking back on it, though, these limitations were more good than they were bad. They forced us to constrain our design. We couldn’t drift off into something that would take forever to implement, because we simply couldn’t do it. Nowadays, the situation is a bit different. With Sanctuary 17, I started to peek under Flixel’s hood in order to implement dynamic lighting, and started working with the actual Flash classes that Flixel manipulates. Although it took me some time to get it working correctly, it was time well-spent. I can’t see how we could have done Sanctuary without that lighting system. It’s just an integral part of the game.

With the game we are working on now, I decided to dive head-first into the quote-unquote internals of Flixel, because I wanted to implement a couple things that would at first inspection would be impossible in Flixel. I don’t want to talk about details too much, but as a hint, look at the constructor of FlxGame for one of the things we wanted to do. I ended up spending some serious time getting to know how Flixel handles graphics and collisions, which are the bread and butter of almost every action game. I learned a lot along the way, saw some ways to do some neat tricks… and wasted a lot of development time. I was spending a lot more time experimenting with technical gewgaws instead of thinking about what would actually make for a good game.

A couple weeks ago, we sat back and re-examined the original design we came up with for the game. We cut out a lot of things that weren’t working, and we refocused most of the rest. It also meant cutting a ton of code that simply wasn’t useful anymore. Kind of tough but also necessary. I’m really happy with how things are going now… we soon will have a prototype version we can start showing people and getting some feedback on the mechanics, as we start to fill out all the content we plan on creating. When you’re on a good creative path, you can just feel it, I think. And I feel it now.

But there will always be that temptation, I think. To spend a couple weeks if not months trying to do something supercool instead of thinking about design. I think this tension might even be inherent to making computer games, since they’re such a young medium. Even when you’re making games out of chunky pixels, you still want something that will grab people’s attention at first glance and make them go “woah.” Compare literature, whose quote-unquote technical innovations in recent times have been writing a novel without using the letter E and the crazy typography of House of Leaves. This is not a criticism at all — I just think as a medium matures, people spend less time on trying to make a crazy leap forward and focus more on the content itself.

(I’m not sure how movies and this newfangled 3D fits into this theory.)

So to boil this all down into an aphorism of my own: if you’re spending a lot of time worrying about your framerate, it’s probably because you have an unfocused design.

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.

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.