Twofold Secret

We’ve been experimenting a lot with our creative process. For a few months after we released Alight, Joel and I both worked on separate projects in some sort of creative version of communism. From each according to their ability, to each according to their need, right? Joel would do graphics for both projects, I’d write code for both, but we’d work separately on the design and story of each one. It was an interesting experiment but not a successful one. We divided our talents more than we combined them and neither of us was that in love with the other’s idea, so instead of working hard on one project, we half-heartedly worked on two.

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.

– that being the message the first time anyone ever saw the writing on the wall. You have been weighed and found wanting; your empire will fall. When you’re God, you’ve got the freedom to etch your feelings into stone in house of the emperor of Babylon. Billion-dollar international corporations that are feeling a bit itchy about Q4 financial results, on the other hand, have to employ more subtlety.

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.

So we exhibited Alight at Gamescape this year, an exhibit at the Baltimore-based Artscape festival. And we survived! It was a fun to show the game off, and great to meet up with other game developers and talk shop. There are several big companies in the Baltimore/DC area, but thus far, it’s been hard to find other indie devs that are nearby. Go check out some photos from the event if you haven’t already.

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.