Now we’re working on a single concept, but we’re still tweaking our workflow. Although Joel and I live only about 25 minutes apart from each other, in the past we mainly worked together via IM. It was one of the laziest possible ways to collaborate, and though it worked fine for our previous projects, it seemed silly to use long-distance collaborative methods when we had a simple, powerful one easily available: just hang out.

We’ve had a standing weekly game-making date night since the new year, and I can say that it’s been an unqualified success for me. I’m having more fun working on this game, it’s inspired me to work harder in general, and I’ve got more structure when I code on my own. On random weekday nights, instead of throwing random features in based on what I think is needed or (more realistically) what’s interesting to code, I’m thinking about what I can work on that will make our in-person sessions productive. When we’re together, it feels like we’re playing creative leapfrog. I’ll add a feature, Joel fleshes it out with graphics and sounds. Joel builds out a level and needs a locked door, so I add that in. Synergy has become a buzzword but it’s the best word I can think for it.

(Joel, I am also finding out, mixes a mean gin and tonic.)

I’ve also been thinking a lot about how to structure our code. Lua imposes a lot less structure on your code than the Java-inspired ActionScript ever did. At first this is scary, as it’s easy to shoot yourself in the foot. My constant, annoying refrain when we’ve been working together has been you forgot a comma. But once you realize it’s not so bad — at least, no worse than JavaScript — there are some interesting possibilities.

I’ve been thinking about ways I can make Joel more productive as a designer, e.g. how to make it easier for an idea in his head to become an actual thing he can test out. I think the most succinct way to explain how I’ve been doing it is, I’ve been separating configuration from mechanism.

To give you an example, we have bullets in our game. (Quelle surprise, right?) Joel as a designer isn’t particularly concerned with how a bullet aimed at a particular position onscreen decides how to set its velocity components. He is, however, very interested in the sprite each type of bullet uses, and how much damage it does to something it strikes. I’ve split up the definition of our Bullet class into two files. One is the traditional class definition with methods that handle aiming, playing the appropriate sound when it hits a wall, and so on. The second is full of statements like:

Weapons.basicBlaster.bullet = { width = 16, height = 16, damage = 10, speed = 800 }

It’s code, but only just barely. It’s closer to shudder XML in that it describes data only. So what? you may ask. This could easily be done with constants inside the class definition. But there are two advantages here:

• All of the data that we could consider user-accessible sits in a separate file — there’s no way to mess up the core behavior of the class by accident, nor does Joel have to understand a line of my code.
• More importantly, it’s considerably easier to add new content. Imagine we have a Turret sprite set up in DAME that has a property named bulletType. To make a turret shoot a wholly new type of bullet, all Joel has to do is change the bulletType to a new name, then add a corresponding entry in the configuration file. I don’t have to write any code myself to make it happen.

We’ve never separated mechanism and configuration this much previously; each time we needed to load some data from text file, I had to write a custom importer. It’s not difficult, but it is relatively time-consuming, especially because the easiest format to parse is CSV, but CSVs are brittle. Imagine that you decide a CSV list of enemies should have its lines formatted in this order:

1. X position
2. Y position
3. Enemy type

It’s fine until you realize you need to add a z-index so that bird enemies appear above snails. Either you append the new bit of data at the end of the line, which gets awkward as you keep amending the format, or you rewrite the importer to do the right thing. Either way, you’re spending time working on things that are not actively making your game better.

I realize this approach is adding complexity. It’s dangerous to spread the definition of a class out among several files, since you don’t want to play hide-and-seek in your code. But I think putting require 'settings.weapons' at the bottom of a source file is clear enough. The closest analogue I can think for this separation is the classic .c/.h division the C language makes.

It remains to be seen how effective this will turn out to be. We only started doing this last week, but it feels intuitively to me that we are going in the right direction. Ironically, the more independent we can make ourselves, the more productive I think we’ll be.

Adobe’s missives this past week have been fun to interpret in a bread-and-circuses way, as one more blow in the HTML5/Flash slugfest. But once you’re done glowering or cowering, you end up with the question: what does it mean for me and my work? I think Richard Davey’s analysis of the situation Flash game developers find themselves in is spot-on. Very little has changed this week for people who target Kongregate or Newgrounds, and it may not yet change for a good long while. But the crucial point is it will change. And I feel it’s likely we’re going to be left out in the cold.

Joel and I are the worst kind of Adobe customers: the kind that don’t pay them a cent. We use the free Flex SDK to produce our SWFs, not Flash Professional. We write our code in FlashDevelop, not Flash Builder. Heck, we don’t even use Photoshop. I use the GIMP because I’m a cheapskate with no art skills, and Joel uses GraphicsGale because it’s better suited to pixel art.

To be honest, this is the only reason why we were Flash developers in the first place. Joel has tried to sell me on the idea of using Game Maker or Construct (the old version, not the one that outputs to HTML5). I said no because I fundamentally believe that learning a proprietary programming language is a waste of time. The company goes poof and all the work and knowledge you invested your time into goes poof too.

If this were an Old Testament story, by now I would have been struck dead by a bolt of lightning for hypocrisy. ActionScript 3, while based on the open standard ECMAScript, is Adobe’s baby through and through. But I think I could plea my case down to a debilitating skin disease, because ActionScript 3 has an open spec and a free (with a lowercase F) compiler. At least that was what I told myself so that I could sleep at night.

So we were happy freeloaders until this week. When Adobe announced they were giving the Flex SDK the Google Wave treatment, it was the writing-on-the-wall moment for me. If I were going to guess what will happen next, it will be that Adobe will streamline Flash so that it becomes like Dreamweaver: a WYSIWYG tool that outputs to an open standard. I can see that this would be useful for tons of people, but not me. I never wanted a timeline or a library. I want to plug code and images and sounds into a compiler and get a game.

This week I’ve been looking at alternatives. My criteria have been:

• No proprietary languages!
• Performance on par with Flash Player or higher. To give you an idea of what this means to me, I wrote a simple benchmark that creates as many sprites as possible that blit a static image onscreen and bounce up and down (using simple Flixel-style physics calculations). On the standalone player on my laptop, I can get about 2,000 simultaneous sprites before the FPS drops below 55. Not bad, Flash!
• As cross-platform as possible.
• As easy to code for as possible.

HTML5

The obvious choice since it’s responsible for the aforementioned writing-on-the-wall. But it’s not a complete replacement for Flash… yet. For one, the audio format situation is a classic WWW problem. Every browser supports a different set of audio formats. What this means is that every sound you create has to be encoded in both Ogg Vorbis and MP3 format, which is annoying. I know there are command-line tools that you could leash together to automatically generate these formats, but I haven’t had the time to try to write a .bat script (ugh) to make it work.

The other bigger issue is packaging up the end result. You generally make money with a browser-based game by selling a license to a site and then locking a game to its domain, or by displaying ads in your game. Both methods are easily circumvented in HTML5 right now. Thanks to the mass of unreadable JavaScript code out there, there are tons of tools to help parse obfuscated code. And maybe you’ve heard of AdBlock?

I’m hopeful that someone really smart will come up with a way to make the existing publishing model work with HTML5 content — some way to wrap up all the individual files that go into a game into a single package. But I’m not sure it’s possible. Openness was a large part of why the WWW succeeded in the first place. Curious how someone made that text blink? View source– it’s right there. Trying to work against it seems similar to teaching a dog to walk on its hind legs: it may work for a little, but you’re trying to get something to do something it just wasn’t designed for. More likely, a new publishing model will have to be established. Either way, there’s room here for smart people to make a ton of money with a good idea.

So in summary, my feeling on HTML5 is similar to Richard Davey’s. It’s 80% of the way there and I can envision a day where it will be 100%. But I’d rather not fight the fight to get it there.

PyGame, Pyglet

Both of these are frameworks for Python that bind to existing libraries to do the heavy lifting of graphics rendering and sound output. PyGame uses SDL, which from what I can gather from skimming the Web is venerable but growing a bit long in the tooth. Pyglet uses OpenGL directly. Both of them work on Windows, Mac, and Linux.

I preferred Pyglet’s API a bit more than PyGame’s, but both seemed reasonable. The showstopper for me was performance– I could get at most a thousand sprites onscreen before the FPS began to dwindle. Somewhat unbelievably, the performance hog was not drawing that many sprites onscreen, but the logic I wrote to handle the physics:

self.x = self.x + self.velocityX * elapsed
self.y = self.y + self.velocityY * elapsed

if (self.x < 0 and self.velocityX < 0) or \
   (self.x > 640 and self.velocityX > 0):
	self.velocityX = self.velocityX * -1

if (self.y < 0 and self.velocityY < 0) or \
   (self.y > 480 and self.velocityY > 0):
	self.velocityY = self.velocityY * -1

Not particularly spectacular, but as soon as I commented it out, performance shot up again. It seemed Python itself was the bottleneck. I tried using PyPy because it purports to improve performance considerably, but I couldn’t get it to work either on Windows or Mac. In both cases it crashed mysteriously.

So — perhaps good for games that aren’t overly ambitious. A thousand sprites is nothing to sneeze at. (The SNES only offered 128.) But I wondered if I could do better.

C++ and SFML

I thought perhaps it was time to bite the bullet and start using a Serious Language, and languages don’t get much more serious than C++. The last time I used C++ was in college, more than a decade ago now. After digging in a bit, it seems less scary to me than I remembered it. From a complete novice’s point of view, it looks like a lot of effort has been spent so that you never have to touch pointers directly anymore. There are classes in the STL to handle basic data structures like vectors, and classes have been recently added that help manage memory via reference counting. Having spent some time in the past messing around with Objective C and iOS, it was oddly familiar to me, as if it were from an old dream, but I couldn’t exactly remember.

SFML is a cross-platform library that uses OpenGL for graphics and OpenAL for sound. People tout it as a more modern take than SDL, which evidently uses a software renderer for graphics, not a hardware one.

It took me a few tries to get Visual C++ Express 2010 running satisfactorily on my laptop, but it’s a nice IDE once set up. Likewise it took some time to find tutorials that gave me enough information to be able to write up a benchmark using SFML, but when I did, performance was nice — about 4,000 sprites possible, twice the number as in Flash.

Heartened, I tried adding some code to handle sprites and layers and promptly slammed into a wall. C++ is still a Serious Language, and though you can pick up a lot by skimming search results, I came to the conclusion that I was going to need to crack the books in order to know what I was really doing. While I was asking around for a good text to get me up to speed, I tried…

LÖVE

I remember looking at this when Andy Baio linked it off waxy.org years ago and thinking, “So, uh, where are the sprites?” LÖVE is not so much an library as it is a runtime. You write a function in Lua to draw a single frame — for example telling to draw images at various spots onscreen — and LÖVE calls it as appropriate to produce animation. There’s no compile step, either; you drop a folder of code onto the app to run it. (Though there are apparently ways to package up a standalone app, too.)

I also remember looking into Lua some time ago and thinking, “So, uh, where are the classes?” Lua does in fact have classes, but they exist as an implementation detail, not a language construct. On top of this, they are prototype-based, the same way JavaScript ones work. I had been toying with JavaScript’s prototype mechanism back with my HTML5 experiments, and I actually liked it a lot. It’s strange if you’re used to the strict classical approach a language like Java takes, but once you understand it, it’s powerful.

It’s also very efficient. The bouncing sprites benchmark hit around 3,500 sprites. I hesitate to draw comparisons between this and my SFML benchmark, because the code is so totally different. But it’s clear to me that LÖVE is powerful enough to handle whatever we will need it to graphically, and it’s so much easier to write Lua than C++.

It seems like this is our sweet spot for now. I’ve been hard at work setting up a basic framework in LÖVE, and I’ve been mostly successful thus far. The documentation for LÖVE is spotty, but searching the forums takes up a lot of slack. Lua error messages have been consistently confusing when I make basic syntax errors — I often type a period when I should be using a colon, or a colon when I should be using an equals sign. You have to type object:method() instead of object.method(), but you still use object.property. Likewise you have to write { prop = 'value' } in Lua when you’d write { prop: 'value' } in JavaScript. But I’m making fewer errors as I go, at least.

We’ll see how it goes. It’s an adventure, but then everything is an adventure.

It was also our first time showing off our work to the public, and while I think we had a pretty good first try, there were some lessons we learned along the way.

Artscape is kid territory. Maybe it was because the Target Family Experience Tent (seriously, that was what it was called) was right outside our exhibit space, maybe it was the nature of video games, maybe it was because it was a free, family-friendly festival, but a huge portion of traffic to our booth were kids between 8 and 12 years old. Fortunately Alight‘s game mechanics are fairly simple, so most kids could understand the general scenario and could hack the controls. Still, I inwardly quailed a little whenever the kids stopped to read the text — which a surprisingly high number did — because, well, Alight has a fairly grown-up sensibility. There’s no sexiness, but it’s a bit dark. I kind of wanted to refer them to the Shawn’s Bits table next to ours, which was demoing Pond Hopper, a logic puzzle game with cute, very kid-friendly graphics. Fortunately, though, none of the kids seemed particularly traumatized.

Interestingly, the most common question kids asked was: “What’s the goal of this game?” Adults instead asked, “What was your inspiration?”

You need a real demo. We were showing off a fully playable version of Alight. I assumed people would try a level or two, then get bored or otherwise want to move on. Most grown-ups did, but there was a subset of kids who would happily sit in front of the game for twenty minutes or more. It’s a vote of confidence in the game, I hope, but I think it discouraged some people who might have tried Alight but saw someone else at the controls. I think even people who enjoyed the game needed a little prod to say, “Thanks for playing, you’re all done.” It’s just human nature to want to complete things.

The Maniacal Games guys two tables down were demoing a single level that they told me was designed to take about six minutes, and that seemed like a really smart approach. On Sunday afternoon, I switched the demo to Where We Remain – Joel’s idea — and its quick-play nature seemed to work pretty well, too.

You also need a bajillion giveaways. We wanted to give something to people with a Web address where they’d be able to play Alight once it was released, and we needed to do it on the cheap, so I bought some blank business card sheets from an office supply store and tried to print out a simple design. My printer, unfortunately, crapped out in the middle of the process so we had even fewer cards than we wanted. We ran out literally halfway through Artscape and were reduced to pointing out the addresses on the placards we had on our table. Not very cool.

I saw that other exhibitors at Gamescape were giving away glossy postcards, which seemed like the right mix of quality and size. I haven’t looked into how expensive printing those is, but I’m a little afeard to find out. As always, we’re on a $0 budget.

People like big TVs. I brought my computer monitor to the exhibition space — it’s a 21″ one, so fairly big as monitors go. When I got there, though, I noticed several exhibitors had set up flat panel TVs and metaphorically slapped my forehead. I forgot that the flat panel sitting in my living room had a VGA input. As always, people gravitate towards the shiniest objects.

Eat and drink up. I figured that while I would be tired out by the end of each day, it wouldn’t be a particularly arduous experience. Gamescape was indoors and air-conditioned, and we had seats at our tables so we could chill out as much as we liked. I did not get off quite so easily. I ate lunch around 11 AM on Friday, then sat at the table until Joel got off work around 6. And though I drank a bunch of water bottles (thanks, Artscape organizers!), I was starting to go a bit spacy towards the end of my shift, and ended up collapsing into an unconscious, barely human pile afterwards. I basically needed to eat the entire contents of my girlfriend’s kitchen (thanks, kind understanding beautiful girlfriend!) in order to stand on my own two feet again.

I’m an introvert, so while showing off our game to strangers was a lot of fun, it was really draining. On subsequent days, I brought some Gatorade and munchable Goldfish with me, and it worked out a lot better. I was tired at the end of the day, but not dead on my feet.

The other thing I learned to do was let go. At first I wanted to hand-hold everyone through the game, but it’s just exhausting to do so. Eventually, I could tell who needed me to give them detailed instructions because they’re having trouble, and who I could let go for a bit and give myself some downtime.

Lock it down. The main way to interact with the Alight demo was through a repurposed Xbox controller, so I wasn’t worried about anyone breaking the equipment. Still, a petulant 12-year-old girl decided she wanted to fiddle with the volume knob on the speakers and annoy everyone, so once she left, I moved the speakers behind the monitor. (To her credit, I suppose, she stopped fiddling as soon as I asked her to.) Someone else decided to use a laptop at another table that was supposed to demo the Baltimore Gamer web site to check on their Facebook. So, sadly, you have to run a tight ship.

It’s worth it. While 99.99% of people who came up to the table were friendly, I only met one person who knew who we were. He came up to the table and asked me very politely if I was part of Twofold Secret. I said yes and introduced myself. I feel a little bad because while I think he said his name was David, I could be completely wrong — I said hello to so many people. David, or perhaps not-David-at-all, sat down and played, explaining to the woman he was with, “They did Where We Remain.“ I didn’t narrate at all as he played and she watched. I wanted, maybe more than anything else that day, for them to enjoy it, to think it was as good and maybe even better than the two games we had done before, the ones that had made them remember us in the first place. This is the kind of experience you can’t get anywhere but in a venue like Gamescape. This was why I came.

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.

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.

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.

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.

The idea of making a new, enhanced Night Stalker is actually one I’ve been bouncing around for many years, but it wasn’t until we were getting towards the end of Where We Remain that I finally sat down and began work in earnest on a design document for what would eventually become S17. Taken directly from the original design doc, here is the original Overview of the game:

The PLAYER, trapped in a city where killer ROBOTS roam the streets, must make their way through the dark night with only a LIGHT to guide them and a GUN to defend themselves. AMMO is scarce, but the player has the benefit of a SAFE ZONE they can fall back to. Robots are not the only danger, as SPIDERS and BATS can also prove a nuisance; a lethal one, at times.

Obviously, some elements still persist from this original description, but S17 has grown substantially from that early iteration. At first, players were confined to a single maze, and after killing enough robots, would be permitted to move on to the next one. It was very linear, very arcade, and just felt like Night Stalker+.

I started to focus on the themes I wanted to really develop, exploration and isolation, and how to provide a larger context for what exactly was going on in this world. The first big revision switched from discrete levels to a radial layout made up of three “rings” of rooms, where each room was its own distinct maze. Players began in the center, and the mazes would grow more difficult in layout and enemies as the player pushed further away.

The center of the maze became the home of the player’s band of survivors, which was running low on energy and in mortal peril. The player’s job was to head out into the robot-infested maze and bring back the energy needed to keep the survivors going. Once the central bunker was on a better footing, the player would then have to find the exit to the surface and secure a path for the survivors to reach it by reactivating the security terminals in each maze along the way. In this version, activating a security terminal in a room turned it into a safe area, destroying any existing robots and preventing further robots from spawning there.

While this version of the game certainly had more going on than the previous concept, it had two major problems.  First, the player used energy collected from the robots to do pretty much everything. Energy represented ammo, it powered the player items, it turned on the terminals, and it was required to improve the bunker situation for the survivors. Now, obviously energy management still plays a critical role in the final incarnation of S17, but at this stage, it was simply too vital. The player was stuck collecting energy for the sake of improving their own ability to collect energy. The second problem was that despite a more open maze, there was little impetus to explore other than to find the exit when the player was ready to finish the game. New items were acquired by taking energy back to the bunker, so the player had little reason to stray from the easier, central rooms, grinding out robots for energy.

All in all, not a very satisfying situation.

It was at that point that we decided to focus more on the idea of leaving the underground, rather than building up a central bunker. In turn, the story evolved into one of exile — the player was now cut off from their safe haven and thrust into the darkness. It was at this point that we shifted the map into a grid pattern. The player began at the bunker exit, and their endpoint was the exit to the surface hidden somewhere along the edge of the grid. This was getting closer to what I wanted, but at this point the grid was generated with a random start and end point, and connections between rooms formed a larger maze. (We used a standard depth-first maze generation algorithm for this. — Chris) This had the effect of eliminating any sense of choice in terms of exploration, and also felt incredibly tedious for the player when they had to backtrack.

It seemed like the best way to get the full sense of exploration I wanted was to open the maze up completely. Sticking with the grid system, we made sure that each room connected to all adjacent rooms to create a far more organic ability for players to poke around at their whim. Items were moved into the randomly placed “supply” rooms as a bonus for discovery. On the story side of things, I finished a fleshed-out version of just how the player got into this situation, which lead directly to the creation of the “facility” rooms and the entire framework of communication with Rusty.

This is a somewhat trimmed-down version of the many iterations the project took along the way, but you can see that things changed an awful lot from day one. Next time, I’ll talk a little more in-depth about certain elements that didn’t make the final cut and ended up on the editing room floor…

Sanctuary was born from my desire to re-imagine one of  my favorite games from my childhood: Night Stalker (for the Intellivision).  A very simple game about a man trapped in a maze with an endless parade of deadly robots coming after him, it still managed to push my childhood fear button with great effect.  Taking those feelings – isolation, fear of what was coming next – and putting them into a larger context was the driving force behind my early designs for Sanctuary.

The game has changed a lot from my initial thoughts, both in story and in mechanics.  The world was more limited at first, more linear, but as we went through the early stages, the (to me) thrill of exploring the unknown almost demanded to be given more focus.  The plight of the survivors went through many iterations, until it grew into the story of a handful of dreamers with thoughts of freedom being exiled into the darkness.  With each change, more and more moving pieces came into play, and the project grew larger and larger.

Chris, as usual, kept it all together, deftly implementing our changing goals.  It was a learning experience for both of us, but certainly a good one.  Of course, as a project drags out longer and longer, you start to just want it finished. When all was said and done, though,  I feel we’ve created something we can look upon proudly, and hopefully something you will enjoy playing.

Instead of displaying an (let’s be honest, annoying) ad every time you play our game, we are now offering a way for you to directly support us by purchasing a printed, full-color manual that includes details about the game world, strategy tips, and even some behind-the-scenes secrets. We’ve put up a couple pages from the manual on Scribd so you can get a sense of what’s it like before you buy. If you enjoy Sanctuary, please consider purchasing a copy!

More info, including some source code from Sanctuary you can steal use, to come this week.