Mene, Mene, Tekel u-Pharsin (or: why our next game won’t be in Flash)

posted by Chris on 17 Nov 2011

– 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:

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.