No Framework, Just Libraries

Someone asked what kind of framework I used for RSW, so I thought I should add some information here. I didn't use any "framework", because I'm an elitist when it comes to javascript. (You wouldn't know it looking at my code.) Most frameworks have glaring structural problems that I don't want to introduce into my code.

So instead, I'll talk about the "libraries" I used. The first two are written by other people.

Random Numbers
I needed a reseedable random number generator to implement Murphy's Law. I turned down the Mersenne Twist library because of the terrible style, but the ARC4 RNG has a nice structure that fit well into RSW with a couple minor tweaks.

JavaScript Object Notation
I used a JSON library that I found at json.org for formatting. It should also be doing my JSON parsing, but I found it to be a pain in the butt as a parser. Instead, I'm using straight eval. This is reasonably safe from js injection, since all the JSON data is parsed and formatted by the django library on the server.

Base64 and Compression
Originally, I intended to save level data along with solution data in the URL, so I needed a compression algorithm. I didn't like any of the compression libraries I found on the web. One problem was namespace pollution, but I also had high expectations because I had already written a Base64 encoder. You see, most compression schemes depend on something called a "bit-library" to toss bits around in packets other than bytes. My own Base64 implementation is a bit-library, so an intermediate bit-library is redundant.

So, I wrote my own LZSS library on top of my Base64 implementation. It provided wonderful compression for level data, but even with that, I had to admit my levels weren't going to fit in URLs. That's when I added the server-side for storing user-generated levels. I'm still using the library, but only for Base64.

It might not stay dead though. Solution data is now pushing the practical limitations of URL storage. Solution data is too short for effective dictionary encoding, so I need entropy encoding. Either way, with such small data sets, I need to preseed the dictionary/encoding tree, and at the time I settled on a save format, I didn't have enough solution data accumulated to create a good seed. I might try again at some point.

Modular Initialization

As noted previously, I used a modular initialization scheme. It's home-brew, but fairly close to the capabilities found in standard libraries. There are some good modular loading libraries out there, but since I'd already written one, I didn't use them.

Google App Engine

I'm using some fairly basic facilities of the Google App Engine. The only part of Django I use is the JSON library. I save to the BigTable datastore and authenticate using Google accounts. There's a lot more you can do with the App Engine that I have not needed.

Google Checkout

Not one single person has used it yet, but in theory, I'm set up to accept payments via Google Checkout. A word of warning to anyone considering trying this: Google and PayPal both forbid asking for donations unless you have a registered charity. They will take away all your money if you try this. So, I'm very careful to not say I'm accepting donations. I allow people to pay for support for the game. It's a real service, (I released Opera support yesterday for example), so it should be ok, but keep in mind, I'm not a lawyer, and you probably need one if you're going to take in substantial money this way.