The one (and only) counter-argument I’ve heard against SWF protection goes something like this:

It doesn’t matter what you do, thieves will always be able to steal your work, so don’t bother with SWF protection.

This is a textbook example of the “perfect solution” fallacy. Thieves will always be able to crack safes, so why bother storing your money and valuables in them? And of course encryption can always be cracked, so why bother using it when transferring valuable information? Why not just release all your work and hard-earned assets out to the wild for anyone to plunder, since apparently it will be plundered regardless of whatever you do to protect it?

Why try?

Obviously we use safes and encryption &c to minimize the chances of bad things happening to our precious stuff. It’s just the same for people like me who make money with SWF files–I don’t want anyone stealing my Intellectual Property and posting it elsewhere, claiming it as their own, so I do everything I can to make the process of stealing my SWF files as difficult as possible. The more difficult a thing is to steal, the less chance there is of it being stolen–and less often.

This is a quick run-down on the status of the financial options that are available to independent developers who don’t have massive marketing budgets or corporate support. Please post a comment below and let us know how your experience has been with these options (or others I’ve missed).

Flattr

The latest option is a general-purpose micro-donation system called Flattr. It takes the “like”/”retweet” interactive device and applies it micro-funding. Watch this video (1.8 minutes; opens a lightbox) to see how it works; or here’s a summary:

1. Once invited/registered, you fill your monthly “means” account with some money. The devs like to call this account cake.
2. Whenever you click on a Flattr button, a slice of your cake is given to the thing associated with that button.
3. At the end of every month, your cake is sliced evenly and distributed among all the things you flattr’d that month.
4. Likewise, you will receive money from people who flattr’d YOUR content.

You always have to have some cake to give in order to get some cake yourself. That’s the gist, and so far it’s working well. Of the 15k or so users, many got €100 for a month and thousands more got more Euros than they spent (other currencies forthcoming–Flattr is still in invite-only beta). Pretty good considering this service just launched last month (March 2010) and it’s still in private/invite-only beta.

I first released this game through Newgrounds, those poor souls, but for some strange reason it got a much more positive reception than I anticipated. They also made a lot of great suggestions that I have since incorporated into the game.

In this final update I added a storyline intro of sorts. Also added were satallites that can easily cause a ruckus by bouncing off the asteroids, making the field more dynamic (and shows off the billiard-ball-style physics I put into Flixel). I also added space storms that will cause a static overlay to appear, making things more difficult to see (if you run through them). So be sure to avoid those, even though they don’t damage your ship. So click the damn image below to play it already

Or read on if you already have and wish to know how I made TLE and why I decided on certain mechanics and concepts. I’ll start with the obvious–art direction.

Aesthetics

No one–and I mean NO ONE–knew about or even noticed the unique style I used. They thought it was nice-looking, sure, but they did not notice that, unlike other Flixel games, I did NOT scale up the graphics for that pixelated look. I got the pixelation by putting them through a filter in Photoshop. I then manually drew a heavy pixel border around every solid asset (backgrounds/effects/etc do not have any). Lastly I added a heavy drop shadow for everything, giving it all a flat “fake depth”, as if everything was made out of cardboard and kind of laying on top of everything else. I didn’t achieve this effect as well as I wanted–too subtle.

Low-poly, game-ready model of a H&K MP5k. Fully UV-mapped, super-efficient layout, ready for texturing.

Price: $15

Updating cart…

Ultimately, content is a banana and we’re all a bunch of monkeys :: photo by hvhe1 ::

Some loud dude (Ryan Creighton of Untold Entertainment fame) recently posted this article, claiming that content is actually “peasant” (rather vehemently) and that meta-aggregators (he simply calls them aggregators of aggregators) and advertisers are the ones at the top of the commerce chain. I’m going to question that conclusion here.

So. Why would people say content is king in the first place? I think it’s because advertisers, aggregators, meta-aggregators, and, uhm, salesmen (whom Sir Creighton says are the real kings, which we’ll simply call the 3 Horsemen–yes I ignored salesmen) would all be dead without content. That’s a pretty well-established fact. I mean, Creighton is right in that the 3 Horsemen are essentially clever leeches and content producers rather strong-headed asses, but it’s telling how he calls content the “vehicle”–without the vehicle, nobody moves. So there’s definitely some meat to the idea that content is, in fact, king because everything else feeds off of it, and it’s not possible to run it the other way around… unless you want to advertise ads… but then the ads would become content by definition.

Here’s a game I made for this Newgrounds contest. It’s an endurance game where you’re trying to escape some mean aliens in a rocket ship, but you will fail. Please give it a shot though and let me know what you think in the comments (or if you’re a Newgrounds member, please rate/review it here). Click the image below to open the game in a lightbox.

Play it at Newgrounds.

I had been prototyping 4 or 5 game designs over the past several months and during that time I hacked out the core code blocks that eventually made it into TLE. The game itself took me about two weeks of off-on work, with the last few days being pretty intense to meet the deadline. I built it using the Flixel framework.

There is absolutely nothing original about this game. It is not going to win awards, though if I won that contest I would be super-stoked. I mean, you fly a rocket ship and dodge asteroids and alien gunfire. That’s it. Remember SkiFree for Windows 3.1? It’s like that, but in space. I didn’t mean for that to happen, it just did. Coincidently, I hated SkiFree as much as I hate TLE.

NOTE: I am aware of the slowdowns. I upgraded Flixel to the latest version at the last minute due to some unforeseen requirements and it’s been bad since then. I’ll look into it when I’ve had more sleep.

And yes, it runs perfectly fine. I’ve run it at 60+ FPS with 7,000 particles, but that actually isn’t the limitation (unless your particles are crunching heavy math for eg movement). Rather it’s the size and number of sprites that we’re colliding with the particles. Click the image below to pop a lightbox with the demo:

To squeeze all the juice out of Flash I employed a couple tricks. The first was the particles themselves–they’re blitted to a single bitmap which is used as the source image for grabbing collision data from. The particles are also drawn with the raster engine in Flash (multiple setPixel32() ops to give the illusion of a line… a choppy one anyway) instead of the vector renderer (lineTo()). The second trick was to only grab a Vector of pixels from the regions we cared about (within sprite boundaries) every so often, then to loop through the Vector and test it against our desired conditions. Also, since the particle bitmap is more sparse than our sprites as far as opaque pixels go, we test the particle bitmap first, resulting in a lot fewer passes on the first round of conditional statements.

When iterating through an array that was generated by some built-in function (such as getVector()), check to make sure you’re rounding the input first. If you get an “out of range” error but your code is fucking perfect, then it’s probably because the rectangle used as input by getVector is skipping a row of pixels because the x,y of said rectangle is being rounded UP. For example, 12.51 becomes 13 but since the rectangle is limited by certain dimensions it simply (stupidly, moronically, fucking ridiculously) truncates the dimensions by one row or column. So when it turns the pixel data into a 1D array it’s missing a whole chunk of data which causes your pre-computed (with the correct dimensions) array length to be too high… hence the iterator will hit a number outside the array’s range.

Judging by the number of results Google returns, this is a pretty fringe case (that or I’m exceptionally stupid… hush). Regardless, it’s a problem that has been plaguing me for the past few months. If it weren’t for my genius programmery brother I would have never found it either. But thanks to him I’m now savvy to what’s termed as “rounding errors”. They even sound evil.

Here’s an example with code…