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.

Click to see details »

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.
Click to see details »

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.

Click to see details »

When I set out to write a very simple Pixel Bender (PB) kernel/script thingy, I expected it to be relatively straight-forward, mostly because Adobe has been so good writing quality documentation for its products and/or there is a wealth of info on their products produced by their users. Unfortunately I didn’t find the dev guide in the Help menu and I missed some key AS3 bits from the links I’ll post below, but even so I still had a lot of trouble finding some info that really should already have been out on the interwebs. So this post is to fill in the gaps when going from AS3 to Pixel Bender.
Hope it helps

Best resources for beginners

Here’s the best tutorials and explanations I’ve found so far:

• The official guide and reference. Slap that F1 key! Also, don’t forget the Help menu in the toolkit like I did (there’s the PB-specific language spec and dev guide there).
• Using PB as a calculator. Completes the official tutorial.
• Great in-depth article with general+performance tips.
• Very straight-forward examples + comedy. Can’t go wrong there.
• Nice user article on optimizations and some speed tests (turns out, for input bitmapData beats ByteArray beats Vector.)

Syntax overview

As a casual programmer of high-level languages and no mid- to low-level ones, I was thrown off by PB’s awkward syntax. It’s strongly typed, which is fine, except I’m not familiar with low-level languages like C or any previous shader language (PB is based on GLSL from what I hear). Here’s a basic difference:

AS3: var i:Number = 12;
…in PB is: float i = 12.0;
The decimal in 12.0 tells PB it’s a floating point number. If it was just 12 PB would think it’s an int.

When dealing with “vectors” (which are arrays, as in Flash 10’s odd use of the word “vector”) it’s float2 i = float2(12.0, 2.0). Notice there’s no brackets or anything suggesting any type of array present. It’s simply the type + how big the array is, eg float3. It goes up to 4, for the 4 channels in images: Red, Green, Blue, Alpha). Then, as you can see, intializing the array is a simple matter of putting in the numbers you said would be there. So float4(1.0, 24.2, 0.1, 3.4) is valid whereas float2(1.0, 24.2, 2) is not, because there’s an extra number in there and it’s an int (adding insult to injury).

Click to see details »

Makin’ games

I’ve been working on a couple game concepts and want to prototype a few more before committing to one to build out. I’ve been hacking the hell out of Flixel, which I’ve decided to use for a most of the games. There’s a screenshot of game3 on the right there. Weird, eh? Also fugly, but it’s placeholder art so there. I have a new collision detection system for it that I’ll be posting about eventually (at least, I’ve never heard of it before).

The microtransaction (MTX) dilemma

I’m really excited about all the new services that have been released to allow Flash developers to monetize their games through microtransactions. I fucking hate ads, plus the ROI of them in Flash games is usually shit. Many many years ago I knew microtransactions (MTX) were the future of digital content and I’m pleased to see the idea coming to the mainstream (in America at least, Asia was quicker on it as usual).

The problem I’m seeing with MTX is that Flash developers need to try a lot harder by making much bigger games in order to really reap the rewards. Before, you could make a pretty simple, fun and addictive game and monetize it easily with ads. But with MTX, you can’t do that as easily since you need to build more content for players to buy into. For example, to me, putting premium content in a Tower Defense game isn’t viable–the game concept is so small that I doubt anyone is going to pay anything for more turrets or maps (for example). There just isn’t enough game there.

Click to see details »

What I wanted was a fast, seamless way to transition from clickable thumbnail on a zui canvas while dynamically loading the content of whatever the thumbnail represented. I just loved the idea of loading content while zooming into a thumbnail without loading a higher-res image to take its place, then having the pixelated thumbnail disintegrate to reveal the actual content that got loaded during the transition. Anyway, it was the best idea that I could come up with for my application, so here we are.

Click to see details »

I’ve been messing around with particles, particularly the blitted, traily kind I guess. Click on the image below to pop and watch it. Grab the source at the bottom and let me know if you do something cool with it.

Click to see details »