Today is day 7! I was really hoping I would have the game finished today, just to say I made the game in a week – but after 7 hours of work I’m having to forfeit. I’m travelling out to see the Indie Game: The Movie screening in Winnipeg early tomorrow morning, so I’ve got to pack and get prepared tonight!

The done stuff

The game is pretty much feature-complete. I took the two divergent core gameplay mechancis and mixed them together into a single, fun unit. There’s all sorts of polish – screen shakes, particle effects, animated (tweened) characters, high scores, game center integration, etc… All the little details that turn a game from a “good mechanic” to a game that actually feels good.

I’ve been playing a lot of the game between builds, which I think is a really good sign. I’m really enjoying how the game feels, and it’s an actual challenge for me.

Sven also got me a set of new art (some of it placeholder, but at least it’s better placeholder than my own stuff!), and I have to say.. it makes the game look completely different. I avoided sharing any screenshots of the game, and was very possessive of who got to see beta copies… Once you see the beta-art, the game is forever stained in your mind, I think. It’s hard to get over that first impression. This new stuff – even half-done placeholders – is way better and I’ll start sharing screens soon!

The not-quite-done stuff

Sven is making some glorious art for the game, and it’s really coming together in a rapid fashion. Unfortunately for me, he has a day job and lives on the opposite side of the planet – so a lot of the assets are still placeholder, and little things like static animations (to make the game really pop) are probably a few days away at the earliest.

But I think one of the worst things, is the game name isn’t settled on anymore. “Word Fishing” was going to be the title, but it’s already a title in the AppStore – time for more brainstorming! (and of course: it’s hard for Sven to do art for the title screen when there’s no name yet).

The official changelog for the day

  • Local high score storage and ranking
  • End-of-game best words list with point values
  • Better GameCenter score handling and timing
  • New set of art – backdrops, character, tiles. Makes the game feel way different already!
  • Gameplay balance tweaks to score and combo cooldown rates
  • Screenshake! Aww yes. Every game feels better with screenshake!
  • Aesthetic changes to particle effects, their numbers, and their behaviours
  • Built a system to swap in random art assets for variety
  • Added the ability to give up mid-game and not lose your score
  • End-of-game screen does a bit more hand-holding
  • Lots of little bug fixes and performance optimizations
 

After Global GameJam, I took some time off to recover. Yesterday (Tuesday) I put in about 6 hours of work… My heart wasn’t really into it (I had a really rough sleep) so I started by kinda just poking at things.

The Evil that is Refactoring Code

I’m a big fan of “just get it done,” and doing it as fast (and as messy) as possible. It’s this skill that allows someone to finish a game for a 48 hour game jam… Or heck, even in the 5 Minute Game Challenge I hold at OrcaJam. I think these skills translate very well to managing deadlines (in more structured environments) or actually finishing your game for the indies out there.

Your biggest enemy in rapid game development is that desire to do things right the first time. Over engineering is the devil! There’s time for that later.

For day 6, though, I was really not feeling that creative. Scrolling through my mess of code wasn’t making things better, and I decided I’d spend some time cleaning up. I shuffled out some new classes and moved things around – ultimately, simplifying and marginally speeding things up. I largely look at it as a waste of time, but there is one small benefit I gained: The exercise of cleaning up the code for 3 hours managed to dust all the cobwebs out of my brain, and I was able to actually get some work done for the remaining 3 hours.

Implementing GameCenter Support

Getting your AS3/AIR application to access some iOS-device functions (such as GameCenter, iAds, and in-app-purchases) is really tough. Sarah pointed me towards Milkman Games and their suite of tools for AIR/AS3 developers, and I thought I’d give the GameCenter component a whirl before I implement highscore functionality.

Yeah, it costs money – about $70 for this piece – but I swear I couldn’t find a single thing that came close to free in months of casual web searching. Getting this kind of thing working takes some talent, time, and some core development skills.

I am pleased to say that with about 10 minutes of reading the documentation and typing out the code, I had a complete GameCenter tie-in working (with score submissions and table browsing)… and it worked on my first compile, with no tests at all. (I spent another 20 minutes setting up my Apple Developer account, but that’s because their forms kept timing out on me. *shakes fists*)

MilkManGames did an excellent job of documenting this package, and even covered some gotchas at the end of their documentation, with sample code too. All in all, it was well worth the money and the package was very well put together. It’s not 100% perfect, and integrating it with FlashDevelop has a few minor quibbles, but I hear FD is working on a fix for that (not MMG’s fault).

Some other stuff

I managed to get a nice tweened animation for the main character as you’re playing, which helps give the game a bit of flow. I also settled on a core mechanic and re-introduced certain elements, like combo-multipliers and timer cooldown systems. I also did some work on the end-game to make it a bit less weird (but still retaining that not-so-jarring experience).

All in all, a good day, considering how I felt at the start. :)

 

During the Global Game Jam, someone leaning over my shoulder remarked on how quickly I was able to dump audio into my game. I’ve gotten quite a few requests for my audio handling library, so I thought I’d make it publicly available here.

I’m no audio expert, and it’s very simple, straight-forward, and to the point. I’m sure it’ll work fine for basic needs, but if I made any huge mistakes or anything… Let me know! I’m still learning too.

RadialSound works seamlessly with any AS3 build, including AIR builds for iOS and Android, but I’m mostly saying that because mentioning “iOS” in my posts increases my web traffic by quite a bit. :3

The File

Instead of quoting all the source I’ll just link to the class I’m currently using, here. I named the file “RadialSound,” to give it a unique-but-short name, and also I’m a big grown up with my own company (Radial Games).

Personally, all of my utility and commonly-used references are in their own simple, flat, one-level folder. I then use FlashDevelop to import that folder via the Project > Properties > ClassPaths window. This allows me to share all of my common code easily across projects, without having to do all that “com.andymoore.crap.”

You don’t have to get all fancy, though; to use this file, just drop it into your project’s root source directory. That works too.

Setup

RadialSound uses a static instance to work across your entire application, but first you’ll need to initialize it. This can be done anywhere in your code, probably near the beginning/first boot of your application:


new RadialSound();

Then you just have to tell RadialSound what audio bits you want to have access to. It’ll accept URLs to audio files (good for streaming in long Mp3s), generic classes for embedded audio, or specific classes from a compiled source (such as SWC libraries of assets). We do this via the “storeAudio” interface, which wants both the class and a label to identify it later:


// Stream an Mp3 in from a web server

RadialSound.storeAudio("track1", "http://test.com/music.mp3");

 

// Standard audio file embedding:

[Embed(source = "fireGuns.wav")]

private var fireGuns:Class;

// And recording that in RadialSound:

RadialSound.storeAudio("fire", fireGuns);

I’ve always been conscious of SWF file size and of bandwidth consumed; you don’t want everyone that loads your SWF file to have to [at least start to] download six tracks of music before they can see the main menu.  What if the majority of your players never make it to track 5? Why waste all that bandwidth? And why annoy players with large .SWF file sizes, too?

You might as well host as much of your audio seperately as you can, and load it on-demand. If you have a particularly popular game, storing your music tracks on cloud-hosted servers (like Amazon S3) might be a good idea too.

To help work with these solutions, I’ve added some extra functionality to the storeAudio interface. By default, it will simply store the URL of your externally-hosted music, but not actually start to stream it into your application until it is actually requested for playback. This can result in a half-second (or worse?) delay in playback, though. You can override this behaviour and force-load assets immediately, if you wish – useful if the exact timing of the sound is important (at least for the first playback):


// Final bitflag determines streaming time

RadialSound.storeAudio("track1", "http://test.com/music.mp3", true);

 

There’s a bit more functionality in there, but I’ll leave it for you to discover.

PlayBack

Now that we’ve told RadialSound what exists, playing them back is simple:


RadialSound.playMusic("track1");

RadialSound.playSound("fire");

I’ve separated music from sounds for a couple of reasons: music will loop indefinitely by default, and will immediately change tracks when you feed it new input. Audio on the other hand will allow 10 (number tweakable) sounds to be playing at any given time – the oldest sound getting bumped for any new requests.

There is also behaviour in the class to mute/unmute all sound, and even a quick and simple way to pass it an art asset and have the class build the mute button for you. Explore! The file isn’t all that big, and is pretty self-evident. :)

All in all, it’s anything you could want from a simple flash audio player.

Again, download link RIGHT HERE to RadialSound.as. Let me know if you improve upon it!

 

Shawn Blais taught me all I needed to know about mobile optimizations of my AS3 code. His blog only has a dozen or two articles, but they are chock-full of interesting information (and even sales figures!). The most useful stuff for me, at this point, is the graphics pipeline optimizations.

The thing that ties the following three steps together is one unifying theory: use bitmaps for everything. You can start with MovieClips and vector Sprites, and you can even stick with Flash’s DisplayList to keep things organized. But the actual image data? Bitmaps! Always bitmaps.

Step One: Use the GPU rendering mode

When designing a mobile application, you’ll have an “application.xml” (or similarly named) file that contains all sorts of nice settings. One of those is going to tell the mobile device whether to render using the CPU or the GPU. Most defaults (including the FlashDevelop template file) will point you to CPU, and that may be fine for flash’s standard vector art. Switching to bitmaps and the GPU setting will give us much better performance.

Open up application.xml and make sure this exists:


<initialWindow>

<renderMode>gpu</renderMode>

</initialWindow>

(source article is same as step 3)

Step Two: Lower the Stage Rendering Quality

AS3′s stage-rendering quality setting determines how vector art (probably your “Sprite” and “MovieClip” classes) is rendered. The thing is, even with a low setting, the stage still respects your bitmaps “smoothing” flag and draws it without any discernible difference. No need to spare the CPU cycles on something we aren’t using!


stage.quality = LOW;

If you have vector art you are loading and converting during runtime (see step 3), AS3 even lets you change the stage quality on the fly! Just use this:


stage.quality = HIGH;

convertMySprite(); // Or whatever your function is

stage.quality = LOW;

(source article)

Step Three: Use Bitmaps, and Cache them

This is probably the best performance-enhancing-drug my mobile apps have used so far, but it only gets the big performance gains if you use it in conjunction with Step 1 (GPU render mode).

The basic idea is to take all of your image data, and cache the bitmap data only once - dynamically – to a dictionary reference.  In GPU render mode, this stores the data as a texture in GPU memory on the mobile device. As long as all duplicate images are pulled from the original data, no new memory is used and creation of new graphics is lightning fast.

This works particularly well for common images used frequently – say, badguys, bullets, and common tiles. But I use it for everything!

Shawn’s original article laid out some source code and a longer explanation if you want to get into details and performance charts. His code does all of the conversions automatically for you, and the discucssion in the comments of his article improved upon it. I added a few tweaks myself, and it is now the only class I use for any type of image data. Imported .PNG file? Sprite or MovieClip in a .SWC? Class reference to an object you custom made? Doesn’t matter! All automated, all quick, all easy to use. Best of all: the code is really short, simple, and easy to read in about a minute. 

It’s a bit too long to paste here, so here’s a link to the class I use right now. Feel free to use it, just let me know if you improve on it :) Copy and paste it to the root of any project and you should be able to start using it right away.

(source article)

Bonus Step: Convert MovieClips on the fly

I haven’t tried this step out yet, but it’s an extension of the class I offered up in Step 3: automatically convert each frame from a MovieClip to cached bitmap data (and store that stuff in the GPU). If I had animations in my most recent games, I would be all over this too!

The Drawbacks

The biggest drawback I’ve found with the GPU-rendering mode is that you lose your runtime access to all filters and blendmodes. If you want to put a nice glow filter on a flame graphic, it’s easy to pre-bake that. But dynamically adding things – like adding a stroke to a font – are pretty hard to workaround (using system fonts, as opposed to spritesheet based font rendering). Hit me up if you have trouble with these, I’ve found some solutions (but not all).

A secondary detriment is that a complex DisplayList will slow down your app a bit more than usual. Try to avoid nesting that goes too deep. But you were doing that already, right? ;)

A compounded drawback here is that GPU-rendering isn’t available on your desktop (without Stage3D routines). That means when you do a test-run of your mobile app on your desktop, you will still see your filters and blendmodes, which can lead to some confusion, particularly if you’re porting a complex app written for desktop use.

The Gains?

The most complex scenes I’ve created with these methods run beautifully on my two-year-old Nexus One. I ran an hours-long performance test on my iPad – constantly drawing new moving objects to the screen (and never removing them). Though things (understandably) dropped to about 3FPS after quite a while – memory usage was nominal and the app never came close to crashing.

Most importantly, and this is a pretty big thing: this performance boost is BETTER than what you get from blitting on a mobile device. That means following those 3 basic steps will give you better performance than Flixel and FlashPunk’s default rendering engines.

In many cases, it’s possible for your mobile devices to outperform your desktop thanks to the direct GPU access. Hopefully this will change with Stage3D? Until then, blitting engines (like Flixel and FlashPunk) are probably your best bet for desktop and browser performance.

For all sorts of performance charts and figures, stress tests and numbers, check out Shawn’s posts (linked in the respective steps above). He sees up to a 4000% speed boost.

 

I’ve gotten a lot of EMails over the last few days demanding to know how I can make mobile games on a PC.  Some ask about Android, most ask about iOS, and everyone is all jaw-agape that AS3 code runs on these devices in some sort of native format (as opposed to in a browser instance).

Then they get all wobbly in the knees when they figure I’ve done it using completely free software.

There are plenty of (IMHO: Over-complicated) tutorials out there, and my knee-jerk reaction is to just … well, LMGTFY. After all, I didn’t divine this knowledge myself; it came with a  bunch of research, and thankfully following the path of other people.

I think I can simplify most of the tutorials though. Check it out.

Step 1: Boot up your PC.

These steps are for Windows operators only. The software listed here doesn’t play well in Apple environments, but then again, Apple users don’t have a lot of the iOS-related problems I do in the first place.

Step 2: Install FlashDevelop.

When I say “install FlashDevelop” I mean for you to install the latest version (4.0.1 RTM at the time of this writing). This is important: the next few steps don’t make any sense if you go even 1 version older. Also, don’t mess around with the default install folder, and don’t mess around with what sub-components are selected in the installer.

FlashDevelop is a development IDE, similar to Flash CS or FlashBuilder, except this one is free. After it installs, it also goes ahead and installs the Flex SDK (free flash compiler) and the Air SDK (the magic bit that makes it work on phones) automatically for you, and then links it all up internally – saving you like 4 dozen more steps.

Step 3: Start a new project in FlashDevelop.

This one’s easy. Open up FD, select “NEW PROJECT” from the “Projects”  menu, and select “AIR Mobile AS3 App” from the list of templates. This is the magical step that will auto-generate for you a bunch of instructions, batch files, certificate directories, and everything else you’ll need to get going.

You don’t need to even bother writing a quick “Hello World” application, as this template should compile immediately for you. Just hit up “Project > Project Properties” and give the app a bright pink background, then hit F5 and watch it run on your PC.

Yup, at this point, only at Step 3, you’ve already got your mobile-device-simulator installed (a cheap AIR projection version anyway), and you can start developing your application.

Step 4: Follow the included instructions.

The best part about FlashDevelop’s mobile project template is that it includes two text files in your project directory:

  • AIR_Android_readme.txt
  • AIR_IOS_readme.txt

They’re both around 6-steps long, and in painstaking detail (with web links, references, and cited blogs) tell you exactly how to get your app working on your mobile device.

After following those instructions, you’re DONE! That’s it! You are now making games that compile and run on the precious iPads of the world.

Now, those extra text-file steps can be easy (if you’ve setup certificates and things before, or have your phone drivers installed), or they can be new and intimidating. So I’ll outline some of those steps here. I’ll start with Android to give you a baseline of what the experience could be like:

Step 5: Install your Android USB Drivers.

There’s a link included right in the readme file to a website that just asks “What kind of phone do you have?” and points you to the appropriate download location. Easy as pie.

Don’t forget to turn on “Debug mode” on your android phone at this point (Settings > Applications > Development menu).

Obviously you only need to do this once.

Step 6: Generate an Android Certificate.

FlashDevelop automatically made a “generateCertificate.bat” file in your project folder. Run it. Yes, it’s that easy. And yes, this only has to be done once as well.

Step 7: Run the game on your Android Device.

Plug your Android phone into your (rear) USB ports, then edit “run.bat” in your project folder. There’ll be a little commented-out section that says:

goto desktop
::goto android
::goto ios

Just comment out the desktop line, un-comment the android line, hit F5, and BAM.

You’ll see your game fire up on your Android device.

I am serious, it is REALLY that easy.

Step 8-ish? iOS Steps?

iOS setup is a teensy bit more work; it requires the installation of Open-SSL (or an equivalent if you don’t already have one installed) for certificate generation. And it requires you to pay $99 to Apple if you haven’t already, and requires you use their development portal to generate keyfiles and things called “mobile provisions.”

You see, Apple is terrified you will take a compiled application, and put the .IPA file up for sale on your own website – circumventing their internal app-store. To get around this, they require that all your beta/in-progress software specifically list each device you are intending on testing it on. The only way around this is to sell the app through the app-store.

A “provisioning certificate” is an encrypted file that contains all the unique device IDs, and your unique game ID, all in one place. When you compile you’ll need this certificate.

But, you only have to do all that setup once, and not necessarily per-project. And again, those steps are clearly detailed in the included readme file. Take it step-by-step and you won’t mess anything up.

The final step here could be you installing iTunes, and trying to install your app there and transferring it to your iDevice. I highly recommend signing up for TestFlight instead; it’s totally free, and it removes a dozen headaches and makes this whole step way easier, and allows you to easily distribute the builds to your partners/beta testers. I don’t even have iTunes installed on my development laptop.

Selling your Game

For Android, there’s not really any extra steps here; just upload your finished product to the marketplace. Done!

For iOS, there is one unfortunate final step. Apple decided to remove their webpage-based upload-to-app-store feature several months ago; you do need (at this time) access to a Mac simply to upload your .IPA file to the developer portal. But that’s all it is: uploading a file. If you have any friends that own a Mac, you can just beg/plead them to do it for you; or maybe by the time you are reading this, us PC developers will have finished writing another work-around.

Frustrating, I know, and I hope this won’t be a problem for much longer.

To sum up,

It takes 3 very easy steps to get started developing mobile apps.

It takes 3 additional (very easy) steps to get starting pushing it to Android devices, or 5 additional (annoying) steps to get it pushing out to iOS devices.

And one final step to sell your application in the marketplace.

 

I run the local Victoria game developers group (LEVEL UP!), but our sister group in Vancouver (FullIndie) was having it’s one-year anniversary last week and I was invited over to give a nice short talk of some sort.

The Trip

I had a blast on the trip. FullIndie had probably over a hundred people show up for the birthday celebration, and we all went roving across three pubs after our talks. It was great to meet so many new people – but the size was a bit overwhelming! I couldn’t even meet everyone if I tried.

I took my FlashGamingSummit talk and slimmed it down to around 14 minutes (originally 60 minutes!). I basically cut out all the “facts” and just left the jokes and the summary “lessons learned” and tried to quickly barge through it all. Because of the size of the meetup, I actually had to give the talk twice to two seperate groups of people! They were both laughing most of the way through though, so I think I did a good job. :) It was a lot of fun for me anyway. A student was there filming one of my talks, maybe it’ll find it’s way online someday?

SteamWorks Brewpub let us into their secret cellar meeting room, which was pretty cool. Had some awesome pints and talked my throat raw. Good times!

The day after the event I hung out with some new friends, played some prototype video games, and even got a few board games in. Wonderful trip.

Since Victoria is on an island, seperated from Vancouver without a bridge – we have to take a 1.5 hour ferry ride between the two places. During the day, the view is beautiful and inspiring, as the ferry weaves between the Gulf Islands. At night, the wind and chill is usually so great that it’s best to huddle inside and do something productive…

I decided to do a GameJam!

The Jam

I was jamming on my own but I invited others along via Twitter. I did a screencap of me working at night spliced with the earlier trip during the day. Check out my rough editing skills here:

(Thanks to DVGMusic once again for his awesome tunes that accompany the video.)

In the end, I made an educational game that attempts to teach people fractions. I didn’t have a lot of time so a lot of elements are missing, and it could definitely use some work – but it might be a neat app to develop further in the future. My girlfriend teaches math, and she approves! Check it out the first prototype here:

AheadFull!

(You’re supposed to be at the speed controls of the ferry, being shouted orders by the Captain.)

 

A few days ago, I posted an article about BlackListing Portals, and other circumvention techniques used in the creation of SteamBirds.

One thing I didn’t mention in that article: Content is the best prevention measure you can invest in. No matter how many prevention measures you put into your code, always ask yourself how long it will take someone to simply re-do your game from scratch.

You might recall that SteamBirds took me a single month to make. A lot of that one-month period was iteration, playtesting, and balancing. How long do you think it would take someone – using the game as a read-only template – to re-create it from scratch? They won’t have to go through all the R&D you did – they can skip right to the end! No waiting on feedback for weeks on your UI design, instant results!

I know from first-hand experience that the answer can be as low as 16 days. 16 days after the launch of the original SteamBirds last year, a clone appeared on the iPhone – with all of my mechanics, UI layout, and gameplay-balancing-tweaks duplicated. Not duplicated from ripping code or decompiling assets – duplicated from just glancing at SteamBirds and playing with it.

That beat the official SteamBirds iPhone launch by over 6 months.

Thankfully, in my case, they didn’t steal the title of the game – or any of the art assets. It disappeared into obscurity with very few sales – proving once again that you need a successful IP under your belt, or else you are going to have a rough time in the AppStore.

The only way to defend against these kinds of cloners is to make bigger, longer, or more complicated games (eg: having multiplayer servers). It’s also more difficult to clone a massive, supporting community (thanks DanC!) – or things like marketing efforts. Shy of patenting gameplay mechanics (which is a very expensive and not very lucrative industry), there isn’t even a legal leg to stand on against these guys.

 

Getting assets (such as images and sound files) into your AS3 project can be simple, but I ran into a few problems (and nice solutions!) that might help others out too. I thought I’d jot it down into a blog post!

How I used to do it

I use FlashDevelop, and I try to avoid using the Flash IDE for development. I found it incredibly handy, though, that I could copy any asset – even vector art – with a simple drag-and-drop into Flash, and export the whole bundle as an .SWC file.

FlashDevelop is awesome handling SWC files; a simple pair of clicks gives you full access not only to the assets, but any sub-classes and properties the assets may have (as imbued by Flash itself). It’s quite awesome, and it’s how I’ve done everything to-date.

The Problem

There are a few downsides to Flash’s SWC asset library:

  1. Porting to other platforms or languages (that don’t support Flash files) is a pain in the butt; without SWC support you have to re-invent your asset importing routines for each platform.
  2. Even when sticking with Flash, importing assets into Flash that you’ve already separated out into individual files can be annoying and tedious (as opposed to developing all your assets within Flash or Illustrator)
  3. You need to own a copy of the Flash IDE (the Professional version, too, if you want to make commercial projects)

The first item on that list is the one that bugged me the most. No other development environment has a standardized equivalent to the SWC Library; converting your game to any other platform or language suddenly gains an extra hurdle, and requires exporting of assets and all sorts of hoop-jumping.  I know this first hand; there was some problems creating the mobile editions of Steambirds.

When I look at various Flash blitting/game engines, such as Flixel and FlashPunk, and they tend to support sprite sheets, image file imports, and other such “industry standard” ways of doing things. Converting from these engines to – let’s say, iPhone – will be a whole lot easier.

There’s just one little thing standing in the way of me following in their path…

I hate SpriteSheets

SpriteSheets were invented by old console programmers that couldn’t manage their assets with the hardware they had. Instead of making large images, they’d break everything down into sprites – dump them all into a single crammed-in file, and re-construct environments piece-by-piece. This is what gives Super Mario Bros. that square look, and why so many games seemed to be built on a grid.

SpriteSheets nearly require you to make all of your assets the same size, and even if you don’t: Any time you save managing dozens of tiny files will be made up in creating a lookup table (or a map) to your spritesheet.

Alternatives?

Well, the standard way is to “simply” use three lines of code to “Embed” each graphic file – at compile time – to your Flash application. I’d love to do this, but I have over 200 files to import!  That’s a lot of typing!

Some helpful Twitterites suggested I might want to look into streaming the files off of a server – but that brings up bandwidth and offline-compatability concerns (but is otherwise a great idea).

Whatever am I to do?!

@ChevyRay to the Rescue

Chevy, the best thing to happen to GDC 2011, took it upon himself to whip up an AIR application that automatically generates all my Embed tags for me, and stores them into a centralized art asset file!

Download his quick-n-dirty tool here: chevyray.com/stuff/AssetBatcher.zip

It did exactly what I wanted it to, simplified a lot of work, and has made my future projects even more cross-compatible with other platforms (and easily portable to other languages).

Thanks Chevy!! <3

 

In the “by the numbers” post a few days ago, I mentioned SteamBirds: Survival introduced a new black-listing technology. There’s been a lot of interest in what exactly this is, so here we go!

First up, I’ll lay the groundwork so you can understand the reasoning here.

How the Flash Ecosystem Works

There are usually a few different “versions” of popular flash games floating around on the web:

  1. The Sponsored Version (primary).The sponsored version typically has no advertisements on it, and minimizes gameplay intrusions to the customer – the games are monetized via other means (such as pay-to-unlock, microtransactions, or placing ads on the website around the game instead). These versions are almost always branded with the Sponsor’s logos. Sometimes this version will have special/bonus content. (Note that you can “sponsor things yourself” by just posting them on your own website.)This version of the game is typically site-locked, so the .SWF can’t be downloaded and re-deployed elsewhere.
  2. The Scraps (secondary sponsorships).Savvy web portals will attempt to profit from a popular game by paying a premium to remove any branding or advertising that may be present. It is common for the fee paid to well exceed a developer’s expected profit for the site via viral advertisements (see #3), thus making this a win-win situation.This version of the game is typically site-locked, so the .SWF can’t be downloaded and re-deployed elsewhere.
  3. The Viral Version.This version of the game usually has in-game advertisements of some sort, and usually some kind of branding for either the developer or the primary sponsor. The game is then put up in various free locations (such as FlashGameDistribution.com) so that any portal may get the game for free.Because no sponsor is paying for this version, the advertisements provide revenue for the developer.

As a case-in-point, the viral version of SteamBirds exists on around 5,000 different websites, which account for around 30% of the game’s total traffic; that’s where I generate most of my advertising revenue (not that there is a lot…).

Arguably more important than the advertising revenue, though, is the branding. Getting your brand (in my case, a link to steambirds.com) in front of millions of people is potentially more valuable than a few pennies for ad clicks.

Which brings us to the big problem.

Evil Jerkwads

Some enterprising portal owners think to themselves:

  1. I see that game is doing really well;
  2. I want it on my site;
  3. I don’t want the developer’s ads on my game;
  4. I don’t want to lose my customers with outbound links;
  5. And I don’t want to have to pay for the game.

They will then grab the free, viral version of the game – and do some or all of the following evil, jerky stuff to it:

  • Remove the ads completely
  • Change ads or overlay their own ads on top of the developer’s
  • Prevent the game from opening links when clicked
  • Replace the links with links of their own choosing
  • Hack out the site-locked sponsored versions to illicitly grab the unique content
  • Replace any/all branding
  • Entirely eliminate credits screens
  • Put their own names into the credits screens

As Adobe’s Flash/AS3 language is an “open” language, there are plenty of decompilers out there. Asset protection is still difficult in the environment. Doing any/all of the above is a trivial process for most developers.

The original version of SteamBirds had around 4 million plays with various iterations of the above list implemented. Most often it’s ad-replacement and blocking of outbound links; I think only one site erased my name from the credits; other games aren’t so lucky.

Flogging with a Wet Noodle

The offenders here are almost exclusively based out of Asia, and most of my illicit traffic comes primarily from China.

Sending cease-and-desist letters from a lawyer, pleading via email, and making angry blog posts in English doesn’t work. Any attempts I have made have gone completely ignored; at best, sites will write back claiming they are doing you a favour by exposing you to a large Asian audience.

It’s hard to bring litigious action against these portals when the value of the traffic they are stealing is diminishingly small. 4 million hits across hundreds of sites? That’s not many visitors each. And it’s hard to put a value on branding, such as “name in the credits” or “outbound links back to my site.” Not to mention bringing litigation against a Chinese site is very difficult to do, thanks to differing international laws (nor would I want to go down that road).

It’s not that I want to shut a single infringer down, or that any individual company is harming me directly in a measurable way; It’s that there are so many of them. Stopping them one at a time won’t get me anywhere. I need a way to flip their entire table over, all at once.

Prevention is the Best Medicine

Because Flash is an open platform, ripping things off is easy. There are certain things you can do to make the whole process more difficult, though.

Simple changes in the way you code, for example, can result in corrective action. If you play SteamBirds: Survival on a site that blocks outbound links, I can actually detect the failure event in the code, and display a popup box that says “This site is being a jerk! Type this URL into your browser bar…”

Using metrics-recording platforms like Playtomic will allow you to track the number of advertising clicks on each site. If there is a lot of traffic with zero clicks, you can take dynamic (code-based-blocking) or manual (off-site blacklisting) corrective action.

And finally, you can use code-obfuscators to help prevent cracking/hacking of various kinds. These automated programs run through your code and change function names to things like ” ” or linebreak characters, amongst other things. I use Kindisoft’s SecureSWF Pro on most of my projects, and I believe it is the best in the industry.

No matter how much prevention you use, you can’t prevent all types of hacking though. With work, any obfuscated code can be reverse engineered; and there is currently no way to encrypt or obfuscate your art assets. Why hack out advertisements or branding when you can just relocate it to be off-screen, or re-paint it as your own?

Enter the Dynamic BlackList

Since I had a nice, long list of badguys from SteamBirds, I decided to put it to good use in SteamBirds: Survival.

Here’s how it works:

  1. I Include the entire list of the offenders URLs as a single XML variable in my code
  2. I then pull a stored GameVar from Playtomic‘s servers to update the list in my code. This prevents people from decompiling the game and just removing their URL from my internal XML (and is quite probably the biggest headache for would-be crackers, since it isn’t an obvious update).
  3. The game tracks ad clicks and looks for other “red flags,” and notifies me of potential infringers. I can then log in to Playtomic and update the GameVar if I believe the site needs to be added to the list.
  4. Upon execution, the game checks the hosted domain against the list. If the site is blacklisted:
  5. The game displays a nice, friendly, pre-made image saying that the game is – unfortunately – not playable on that site, and redirects the player to SteamBirds.com
  6. In case they hack-out the nice art asset I made for the offending sites, the game constructs a much uglier, nastier-sounding “this site is being a jerk!” message from pure code, using no art assets. This is much harder to hack.

It worked really well. The sites that used to be a big thorn in my side? Now very nearly zero traffic. I successfully put up enough barbed wire to discourage the dismantling of my game.

Right after I launched my game, Playtomic released a similar service that covers a lot of the basics: Portal BlackList. It doesn’t have all the bells and whistles of my system, but it provides all the code and integration you need to get a simple system up and running today. I recommend checking it out.

Portal BlackList also shows a list of currently blocked sites in the sidebar. My list is a subset of those sites, so instead of duplicating it here I’ll just direct you there! You can also check out the list on Free Our Games as a reference.

Still Failing

Unfortunately, there are still ways around all of my safeguards. Certain portals will link to your game on your own website, hosted in an iFrame on their own site. Your game then thinks it’s running on a proper domain, while the offending site can strip out any accompanying sidebar ads, branding, or whatever else you might have in place.

Thankfully the number of people doing this is quite small, and not a big deal (for me, anyway).

 

PowerButtonI’m looking for a contractor (or two)! Mostly for the SteamBirds franchise, but perhaps some other projects as well.

Some qualifications I’m looking for:

  • Experience with Flash programming in AS3 (AS2 is a bonus)
  • Knowledge of timeline code, but prefer to code purely in FlashDevelop
  • Knowledge of the Sponsorship-style Flash industry
  • Deep understanding of Blitting with an eye on code performance
  • Mobile development (in Flash and/or native code) is a bonus
  • Strength in Object-Oriented style programming
  • Familiarity with SVN
  • Ability to read my code without clawing your eyes out

This will be spotty/occasional/part-time work to start, but can grow to a more permanent role as the business expands. Renumeration will be based on the task at hand (for example: Site-lock conversions would pay cash up front; larger projects typically work on a revenue share basis).

If you are interested, send an introduction to jobs@radialgames.com.

© 2012 Andy Moore Suffusion theme by Sayontan Sinha