7 Wonders is a card-based game about resource management and building up your city to maximize Victory Point collection by picking an optimal strategy from among a variety of point types.

Game overview

• Fast yet deep gameplay
• Variety of play styles to choose from
• Flexible number of players (3-7 with special rules for 2)

• Steep learning curve
• Poor instructions

The basic flow of the game appears rather complex and unfortunately we couldn’t play the first two times we tried because 1) we couldn’t figure it out and 2) we kept disagreeing over the interpretation of the rules. After a couple of us sat down–away from the party–to grok the damn rules, we were able to grasp the concepts and play an actual game… after about half of the family already left. Basically, the instructions are poorly written and do not provide a good sense of how the game should flow. Example scenarios would have been great. The most lacking aspect was how to handle resources, which is the fundamental aspect of the game. So how they managed to screw that up, I have no idea.

As you can see, there’s a lot of stuff–but don’t fret, once we figured it out, it’s a really fast game with a lot of options for playing different ways.

There are 7 types of wonders for players to choose from (surprise!), although the game calls for players to shuffle the wonder cards (seen above, under the boards) and choose randomly. We liked choosing our wonders and it worked out well for us, so whatever floats your boat. Each wonder has a number of advantages that can be “unlocked” by building your wonder in stages. For the A side (the “easy” side), it’s always three.

Besides building up your wonder (which is optional), you can build structures by laying down the card for it and paying the cost (usually regular resources, sometimes it’s gold). Structures get you all sorts of different things like additional resources, straight Victory Points, discounts on trading with certain neighbors, military advantage, and so on.

What’s interesting about this game is that all players choose one card from their hand, set it down on the table face-down, then reveal their choice when everyone has their picked simultaneously. After you resolve the card (pay for it by buying resources from your neighbors is typical), you give your hand to the player next to you. So through the whole game your swapping hands with the other players, which is an interesting strategic mechanic–knowing what the other players have and having the option to deny them what they probably want by using that card is certainly a fun twist.

You swap hands with your neighbors until all the cards are gone (you start with 7 for each player). After the cards are gone, you progress an Age–and there are three Ages. So the whole game is over in 21 turns! If you know the rules, you can finish a game in under 30 minutes.

Presentation

The cards look and feel great–the art is an interesting, painterly style while the material they’re made of is a pretty standard glossy finish. The “City Boards” are thick, polished cardboard with some cryptic but pretty icons all over them (same with cards).

Thankfully, they didn’t rely too much on color to distinguish between important gameplay artifacts, although it is an obvious identification device used. Unfortunately, they used cryptic symbols everywhere, even in places that should (could) have been text instead (and would have made it easier to understand in the process). Once we got used to the game though, it wasn’t too hard to navigate the board at a glance. However there were some resource symbols that looked too similar, but it didn’t distract me too much.

Overall it was polished and a pleasure to use the provided hardware.

Gameplay

The game is all about gathering resources to build your city. Buildings earn you different kinds of points (such as science, war, commerce, and straigh victory points), so by building different types of structures you will earn either bonuses or points from them that you tally at the end of the game.

Rules

The quickrules that come with the game is a good reference, but it does a poor job of explaining the game. I’ll lay down the basics, then go into how a game actually plays.

1. Each player gets a City Board, 7 cards, and 3 coins at start.
2. Players either put a card down in their board (a resource or structure), or burn the card for 3 coins.
3. Some cards cost something to play, be it resources or coins–either way, you have to be sure you have the required amount before playing them.
4. After ALL players decide what they’re going to do, everyone puts down the card they’re going to play at the same time.
5. Repeat 2-4 until all 7 cards have been played, at which point the game progresses to the next stage. Also, it is at this point that military points are resolved.

Flow

You start by randomly selecting a City Board–each one has a unique strength, so try to play to it to get the most Victory Points. After the cards are dealt, everyone decides what they’re going to do.

For Resources, you simply place them at the top left of your City Board and they stay there for the duration of the game. Some cost coins to play, like the four of those above. Resources are critical to the game, as they are required to play most of the structures (and structures get you points). If you play 2 bricks (add it to your inventory), then you will be able to purchase structures that require 2 or less bricks. You need to have all of the required resources for a card at the time that you play it. When you “use” a resource it doesn’t move or anything, you just have to keep count. On your next turn, you can use any of your resources again to play the next card.

The rest is explained fairly well in the rulebook. You can focus on building resources so you can get any card you want, or you can buy resources from your neighbors using commerce bonuses that make purchasing resources cheaper. Note that players don’t have a choice as to whether you get the resource–you simply put the money on their City Board and you are granted the resource you’re paying for, for the current card/turn only.

For a game called 7 Wonders, the Wonders are surprisingly low key–you don’t need to build all three stages of your Wonder if you don’t want to (but you probably should, as they’re easy points). There are a lot of different ways to victory, and the Wonder only helps a little. Personally, I prefer stacking resources (get a lot of money from other players that way, which count as Victory Points at the end of the game) and military dominance.

Conclusion

What impressed me the most was how they got a game of this depth into play sessions of 30 minutes or less. You get a lot of choices for paths to victory, and you don’t even have to choose one–in fact you should probably choose two, like Science and Commerce, or Military and Victory Points. The designers tried to balance it, but it becomes clear that certain strategies are futile, like strict Science (which, in order to tally the points, requires a strange amount of math to figure out). Science yields a lot of points if you play it right (which is difficult because you need to horde certain cards)… but only if you don’t completely ignore the other aspects.

The biggest reason for the fast gameplay was the simultaneous turns, but in order to make that work, they made all trading obligatory (in that anyone who wants to buy something, gets it). I find haggling pretty annoying so I think this is a fine trade-off. Beyond that you have a solid city-building game that isn’t too cryptic (despite their best efforts with all the iconography) once you get familiar with it (a single full game will do). Highly recommended for a friendly group of 4 or 5, but part of the beauty is that the game scales extremely well, since the more players you have, the more cards you use (each card has a “minimum number of players” requirement at the very bottom).

So how do we get the power of a desktop system into our mobile systems? Streaming. All we need is a screen and a fast connection (4G is probably the tipping point) to bring the computing power and storage capacity of servers into our hands, wherever we are. But streaming isn’t enough–we still need the interactive capacity of a full keyboard and mouse, along with the screenspace of multiple monitors in order to fully realize the power of computing in portable gadgets. What kind of device can make all of this mobile?

Enter augmented reality. With a new kind of head-mounted display that’s essentially special eyewear with built-in microcameras and projectors or transparent LED screens, we can turn our entire field of vision into a fully interactive computing environment. (Here’s some promising tech in that arena–pictured right.) We will be able to take reality and enhance it with digital information pulled from the servers that are processing our input in realtime. And because this augmented environment is completely digital, we can interact with it in any way imaginable. We could use hand gestures (think Kinect, but from the first person perspective), voice recognition, virtual keyboards and other buttons either “floating” or projected onto any surface, and completely new ways we have yet to think of.

The possibilities are endless because we don’t need to manufacture new hardware–it’s all in the software. It would be a lot like the Iron Man interface, except everything will only be displayed through our glasses so no one else can see what we’re doing–unless we want them to. Check it out:

We can bring all the benefits of digital collaboration together with the benefits of physical collaboration with shared virtual spaces. We could choose which information others see and what they can’t. Using advanced image recognition software we can get rid of clunky special objects (like AR markers/tags) and place virtual reality over real objects. There’s been a lot of progress in this area and huge steps are being made every year. Indeed, we may see the augrecon sooner than you may expect:

So this is the essence of the Augmented Reality Controller concept, or augrecon for short. I will be detailing this idea further, providing others with ideas for how, exactly, we can build this with today’s technology. The augrecon is a disruptive technology on the scale of the internet itself, ie a MASSIVE shift in direction. It’s going to be interesting.

Update 2/22/2012: I’ve been thinking about this concept for almost a decade now, and I honestly thought it would take at least 5 more years to really see it come through. It seems it’ll be here much sooner. As in, this year. Apparently, Google will be the first to deploy it’s Android-based glasses. What’s really interesting is that game developers like Valve and id Software are already creating content for these devices, which only makes sense considering games are a primary driver of platform adoption. The specific server-to-HUD design I outlined in this article is fast approaching as well I think, but not as quickly as the HUD itself.

The problem with Flixel’s memory management system is that it doesn’t exist. However, every time you switch states, it does call destroy() on almost every object. The problem is that most of the destroy() functions are completely empty. Obviously, this is not enough.

UPDATE: I got onto github and forked flixel, wrote a patch, and did a pull request. I can’t solve the biggest problem though, which is that FlxQuadTree is being completely recreated on every frame. This is extremely terrible practice and causing the Flash GC to bust ass. I don’t use FlxQuadTree and I recommend building a persistent static grid to handle collisions instead (MUCH simpler and faster than quadtrees anyway). I’m pretty sure the quadtree is causing a huge performance hit alongside the memory thrashing, since my games don’t experience what I see in vanilla Flixel. Good luck!

You will need to go through every class yourself and override (or fill in) the destroy() method to nullify any significant variable in the class itself. Remember to call super.destroy() so that it chains through all super-classes too. Here’s what the FlxObject.destroy() should look something like:

public function destroy():void {
  velocity = acceleration = drag = maxVelocity = null;
  origin = scrollFactor = null;
  _point = null;
  _rect = null;
  _flashPoint = null;
  colHullX = colHullY = colVector = colOffsets = null;
}

Don’t actually use the code in this post–none of it compiles without errors, it’s merely an example (I will be submitting a tested patch for this whole thing to the trunk soon). Also, I’m using the latest build I got from the Flixel homepage–v2.43.

What I’m showing here is pretty straightforward. It just nullifies all object variables so the Flash GC will pick it up. We do the same thing in FlxSprite.destroy(), but we’re going to have to add the function ourselves because for some reason it doesn’t exist. So put this function at the end of FlxSprite:


override public function destroy():void {
  super.destroy();
  offset = scale = null;
  _curAnim = null;
  _callback = null;
  _flashRect = _flashRect2 = null;
  _flashPointZero = null;
  //_pixels.dispose(); // only do this if you don't use FlxG.addBitmap()
  //_pixels = null;
  _framePixels.dispose();
  _bbb.dispose();
  _framePixels = _bbb = null;
  _ct = null;
  _mtx = null;
  for (var i:int = 0; i < _animations.length; ++i) _animations[i] = null;
  _animations.length = 0;
  _animations = null;
}

So those are the first classes to hit. But there are dozens more. Other ones you should get to include (but not limited to) FlxQuadTree, FlxGroup, FlxButton, FlxEmitter, and FlxTilemap. There are a bunch more in flixel.data that you need to do too, in addition to adding destroy code to FlxGame itself.

FlxG._cache and what it does

An important thing to note is FlxG._cache. Whenever you create a new sprite, it stores the bitmapData in that Object. Adam’s reasoning for this was so that only one instance of the BitmapData object remains in memory, so new sprites just reference that one instead of creating new instances. I think this is a pretty solid idea, but I’m not sure how much it actually helps. If anyone has tested this, please post your results in the comments.

Anyway, if you loop through it like I did with FlxSprite._animations though, you will get a ton of null reference errors because you already nullified most of it by disposing of _framePixels in FlxSprite. I recommend adding a new destroy function to FlxG itself and going through _cache and running dispose on each object regardless (IF it’s BitmapData AND not already null)… just to be sure. Don’t forget to null the _cache Object itself.

Cleaning up your own mess

It is very important to override destroy() in ALL of your custom classes to nullify any new variables you added in them. In every class you create, add a destroy() override that also calls super.destroy() in order to ensure that the GC picks up everything. Don’t forget to remove any event listeners as well!

So that’s the memory problem in Flixel and how to fix it. Please retweet this post and share it with others. I think this is an important issue that needs to address in a future version of Flixel, as others are always finding out about it and posting their troubles in the forums. Let’s do our part to keep Flash from crashing everyone’s browser Thanks!

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.

The tools

Right now there are several tools, some even free, that allow you to decompile a SWF file to take a look at everything it contains. This is usually pretty easy because the SWF format is an open specification. This means there’s no way to fully protect anything contained in the file, such as code, graphics, sounds, or videos. However, there are applications that take precautions against decompiling using a variety of methods.

Protectors

I’ll review the biggest names in that market today:

• Amayeta SWF Encrypt 6.0.8
• DComSoft SWF Protector 3.0.1 (on twitter)
• Kindisoft secureSWF 3.5 (on twitter)
• Ambiera irrFuscator 2.1.2 (on twitter)

Decompilers

I’ll be using a combination of SWF Decrypt 1.2 and Eltima’s Decompiler v4.1 to test the effectiveness of these applications. (Side note: Eltima’s Decompiler and Sothink’s are freakishly similar.) SWF Decrypt really upset the industry when Magus (the author who wishes to remain anonymous) released it completely for free. It apparently decompiles any SWF file “protected” by Amayeta’s and DComSoft’s applications. He’s very loud about it too, calling them out on their “tricks”, such as their latest releases (which I’m reviewing here). You’ll notice he left Kindisoft and Ambiera alone, and he claims that’s because they offer real protection schemes, such as renaming functions and variables in the code. But the others claim they also use renaming, so we’ll see who’s right.

The SWF files

I’m a Flash game developer so that’s all I’m going to focus on here–single SWF files containing AS3 code compiled to run on Flash Player 9 and 10+. The files contain references to the Stage object, multiple event listeners, very high frame rates (60fps usually), and numerous computationally expensive operations such as pixel-level manipulations and heavy math functions. Here are the files I’ll be using:

• FlxCollisions
• Mode
• My pixel-level collision demo

These are free with source code available so that I can alter it if the protector requires it. The first two use Flixel (an old and new version), but if you have any (or know where to find some) non-Flixel open sourced Flash games then I’ll try that too. The third is a demo I wrote a while ago that has some heavy computation and sensitive optimizations that could trip up the protectors. Now, let’s get into the apps and see how they perform.

Amayeta SWF Encrypt

Amayeta is a subsidiary focused solely on the Flash platform. It used to have a single product, SWF Encrypt, but now also provides a SWF compression utility. Magus, author of SWF Decrypt, provides a deeper look at their history and he isn’t kind about it.

The problem I have with Amayeta right off the bat is that its flagship product’s name is completely misleading since it’s not possible to encrypt a SWF. I mean you can, but then the Flash Player wouldn’t be able to run it because the player doesn’t have a way to decrypt it at runtime–that’s just not how the player was engineered. So they are being deceitful.

Interface

SWF Encrypt has two main areas in the window: on the left is a file explorer where you pick your SWFs to protect, and on the right is the main area where you check the ones to protect (again) and view their properties.

It has an “encryption” setting with the values of “high”, “recommended”, “low”, and “custom”. If custom is selected you only have the option to set the “minimum data length”, which apparently just lets you put in a number that represents the level of “encryption” to use, with lower values being more protection.

Effectiveness

First using the recommended settings, the SWFs worked fine, no performance hit that I could tell. When I tried to open them up in Trillix, I could get to all the assets, but when I tried to access the scripts, it gave me an “out of memory” error. I tried to put it through SWF Decrypt but then the SWF wouldn’t play at all. I told Magus about this and he’s going to release a new version of Decrypt next week that should break Amayeta’s latest patch. It appears that the junk code Amayeta put into the SWFs actually worked this time.

SWF Encrypt has the options to “encrypt names” which I think is their way of saying they rename indentifiers like variables and functions. But because I couldn’t look into the scripts, post-protection, I could not verify this. I have conflicting reports about whether or not they truly obfuscate code, so I’m going to wait to see if Magus can break their patch, then revisit them again later.

Overall

It appears this latest version actually keeps Trillix from being able to look through it. However, I can’t check to see if there’s any actual renaming going on. Without true indentifier renaming, your SWFs will never be guaranteed to stay safe since the arms race between decompilers and protectors escalates endlessly. So for now, I can’t say one way or another if SWF Encrypt is solid. I can say that the level of control provided by the app is extremely limited, so even if they did do renaming, the user can’t fix a problem if the protection is too aggressive. An option to comb through your SWF and control protection on a per-object basis (ideally, per-variable and -function basis) is needed.

DComSoft SWF Protector

DComSoft has a much bigger catalog than Amayeta, all focused on Flash. Better, but the company history doesn’t appear very legitimate. According to research done by this dude and this dude, DComSoft is the same company as Eltima, a company that creates a SWF decompiler (one that I’m using for these reviews actually). That, my friends, is called “bad business practice”, if true. Besides that though, what the hell is up with the logo? If anyone has any idea what a tire has to do with Flash file protection, please let me know.

Interface

Protector has two modes: Simple and Advanced. Switch between modes using the tabs at the top of the application window. In Simple mode you can batch protect files but there are zero options. In Advanced mode though you can only protect one file at a time, but you can comb through each object and variable and check the boxes next to them, which are “Obfuscate” and “Protect”.

According to the help file:

Obfuscate renames variables, features etc. in a definite way. It doesn’t prevent from decompilation, but makes the subsequent compilation impossible.

And “protect” means

Protect modifies ActionScript in such a way that a SWF file can be played, but it is impossible to decompile it.

Right, we’ll see about that.

Effectiveness

The protected SWFs ran normally with no noticeable framerate drop. When I loaded it into Trillix though, everything appeared just fine with ZERO obfuscation–no renaming except for what Flash does automatically, no junk code/characters that would trip up the decompiler, nothing. All scripts I opened were very readable. I’d like to note however that I’m using an old version of Trillix (4.1), because the newest version would just crash if I tried to open the scripts (well, sometimes it’d work, but most of the time not). Anyway, really nothing else I can say here, just “epic fail”.

Overall

The interface is clean but offers very few options. If it actually worked I’d be ok with that, but maybe they need to add more granular controls so we can pick what we want obfuscated and by how much. It would also help if they added real obfuscation. Regardless, SWF Protector has a few licensing options. The Personal license ($40) doesn’t allow any of the SWFs protected by it to make money, while the Business license ($60) does. There’s other types for companies and OEMs too, but who cares–the software doesn’t work, end of story.

Kindisoft secureSWF

Kindisoft doesn’t mess around. When I emailed them about reviewing their app, they sent back this:

While I definitely love to hear your opinion of secureSWF, we’re not interested to see a comparison with SWF Encrypt and SWF Protector. We think of secureSWF as a professional level ActionScript obfuscator while SWF Encrypt and SWF Protector as single purpose tools that might prevent some decompilers from working for a while.

Ok then. So we start out on a completely different footing with Kindisoft than the others already. But while Kindisoft doesn’t have dirt on it like Amayeta and DComSoft do, it’s still a niche-based company providing only one product. Although that should mean they make a really great product, right?

I’d like to note that the free web-based version of secureSWF that is available to developers who put their games up at FlashGameLicense.com is apparently a different product. When I tried to add its protection to my first game, it broke it. When I brought this up with Kindisoft, they replied saying:

secureSWF is a completely different solution than FGL encryption feature. We built this complementary encryption feature for FGL community to help avoid more thief incidents. It does not use the same technology or techniques as secureSWF.

I just hope their software is better than their grammar.

Interface

SecureSWF is a bit more complicated but makes up for it in options. There are 5 tabs:

The fifth one is just a summary of what it did after you hit the big “Protect SWF Files” button. The GUI is pretty much self-explanatory and gives you a fine level of control. Hovering your mouse over any option will bring up a tooltip that further explains what the option does. So far, looks great.

Effectiveness

The real meat of the app is in the renaming, since eventually all SWF files can be cracked open to reveal their code. SecureSWF does a great job in this area. By default it will leave alone most public functions, probably because they’re usually used by other classes, so renaming them inconsistently would break the SWF.

When I protected the SWF files with the default settings, I was able to play my collision demo and Mode (which uses the old version of Flixel). I could not run FlxCollisions though, instead I got back this error: ReferenceError: Error #1056: Cannot create property D on _-9l._-68. Obviously the renaming was set a little too aggressively for it to work (and the “strength” was only at 20% with most advanced options turned off). When I tried to open the working SWFs with the decompiler, I got an access violation and the program crashed.

Overall

secureSWF only offers variable renaming in their Standard and Professional editions ($200 and $400 respectively), leaving it out in the Personal edition ($100). Considering the functionality SWF protectors provide (and how difficult they are to produce) these prices seem too high to me. The Pro edition (the version I’m using) does provide some nice additional features though, such as removing unused code (it happens), literal string encryption, and solid domain locking controls).

SecureSWF provides users with a lot of options and it would take me all day to go through them all. But the point is that secureSWF utilizes true obfuscation by renaming variables, encrypting literal strings (which Flash Player can deal with), and inserting illegal characters that will trip up decompilers… and sometimes the Flash Player too. So it takes some effort to get working, but the point is that it works. But is it good enough to justify the price? Let’s see what irrFuscator provides for its price to compare.

Ambiera irrFuscator

Ambiera comes out of the gate with significant reputation points for having developed irrLicht and related creation tools–quality open source tools for the indie game developer. Ambiera got into the Flash scene when they decided to extend their game tools to the web via the Flash platform with their own 3D engine and creation apps. They figured developers will want to protect their games and, as the irrFuscator author told me via email, the current offerings in that market “sucked”, so he built his own. With this excellent history of software already under their collective belt, I had high hopes for irrFuscator.

Interface

A quick glance at irrFuscator’s interface will bring a sigh a relief, since the layout is dead simple but all the options are there and well-explained.

If you still have trouble figuring out what’s what, the online docs are helpful and there’s even an active forum for it at Ambiera if you’re still having trouble. Very nice.

Effectiveness

irrFuscator sets itself apart by allowing you to rename all variables BEFORE you compile your project, so you can see exactly what it did and, if it messed up somewhere, you can go in and manually fix it before compiling again. This is the best method of obfuscation since you know it works, you know what it does, and you know you can fix it easily with your debugger. ALL classes and variables can be renamed, plus it removes whitespaces–even Vectors were retyped to the renamed classes, and all packages were also renamed (Flash built-ins as well). The resulting code was impossible to read.

I did run into a few problems though. I tried obfuscating my game, which references an SWC, but when I added it to the list, I got an error saying it couldn’t open it. I just removed it and it continued fine. Also, while it does encrypt literal strings (it replaces them with a function call to irrcrpt() to decrypt at runtime, which will impact performance a bit) it can’t encrypt them when they’re inside an Array or similar data structure. Not a big deal, but I was thrown off by that. The other thing is just a small UI annoyance, which is that it uses Windows’ “browse folders” dialog to pick out your SWF (in “SWF File” mode). This dialog doesn’t remember where you last looked and it always starts you back at your computers root, so it takes me a while to drill down to the proper folder, which wastes a lot of time. Those are the only issues I found though, which is saying a lot.

Using the SWF File mode is nice, but it didn’t work for me; I got back this error when trying to run the protected version of FlxCollisions (again): VerifyError: Error #1053: Illegal override of _iq39 in org.flixel.FlxEmitter. Since this also happened with Kindisoft’s secureSWF, there’s something going on in the latest version of Flixel (v2.35) that gives them grief. Both packages give you ways to work around them though with their fine-grained controls. For irrFuscator, you just have to use the Flex Project option. In secureSWF you can just uncheck that file… if you knew which file that was, but there’s no way to find that out. irrFuscator wins that one.

Overall

irrFuscator has Standard and Professional editions (~$100 and ~$200 respectively–original prices are in Euros). The difference is that the Pro edition has comment directives, which means you can be extremely precise in telling the app which portions of your code NOT to obfuscate using specially formated comments. This is because code obfuscation sometimes results in worse performance or breaks it completely, depending on the code, so this is a great feature. You decide whether or not the comment directives are worth $100 for your projects. Still, these prices are far more reasonable than Kindisoft’s–you get everything secureSWF does at a quarter of the price. Not bad.

Conclusion

I’m bummed that I couldn’t determine how effective Amayeta was, but maybe some of you will think the fact that it can’t be decompiled yet is good enough. Not for me though, because SWFs will eventually be cracked–we need better protection than that. What I did determine though is that Kindisoft’s secureSWF and Ambiera’s irrFuscator offer true obfuscation for sure and therefore true protection of your code. Assets cannot be encrypted and can always be wrestled out of a SWF, unfortunately, so obfuscation is really a Flash developer’s best weapon.

Overall I’d say irrFuscator takes the cake for being reasonably-priced and offering that Flex Project option which makes it very powerful, yet it still retains simplicity of use through an easy user experience, plus the program itself was fast to load and responsive. The others were written in Java or were otherwise slow to start, so they were a bit sluggish.

That’s it for now, but I will be updating this article later if/when we can determine if Amayeta’s obfuscation methods are valid. Thanks for reading

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.

The relevance this service has to Flash games is obvious. Someday soon you will be able to put a Flattr button anywhere in your games and people will be able to easily support you–with all revenue going to you, the developer. It usually isn’t much per click, but it’s still a LOT more than anything ads could give you.

At the moment, you submit your game/post/whatever to the Flattr feed, or create a post for your game in your blog (like I did), and people will be able to flattr you that way. Still pretty easy, but the real deal is when you can directly embed a button in your game (coming soon, whenever they release their REST API and someone writes a Flash implementation of it).

Microtransactions

Microtransactions (aka MTX or micropayments) are not as bad as ads because you get more money per click, but not as good as Flattr because you still have to share your revenue with the MTX service(s) you’re using. MTX are also the most difficult option. Not in terms of coding skill but rather design skill. You have to ensure correct usage/placement of MTX items within your game. Besides that, there’s choosing which service works best for you. You MUST read Lost Garden’s Flash Love Letter that explains both of these factors in great detail.

Here’s the current most prominent micropayment services in no particular order:

come2play took 3 months to respond. For that and they’re disappointing services, they get my infamous “Shit Eater” Award.

“Game extras” means the service provides an API for things like leaderboards, achievements, and other little things that increase player retention and increases general interest and replayability, as well as the all-important analytics tools. Ease of implementation for each service varies, but they’re all pretty careful to make it quite simple. I don’t have any personal experience with any of these but if YOU do then please leave a comment telling us how it went for you.

Note that nonoba is evolving their tools into PlayerIO, a full-blown multiplayer framework built specifically for Flash games, based on a subscription fee (there’s a free version). I’m not sure how their Payments system will handle the move and they haven’t gotten back to me yet. I’d like to mention that the crews at HeyZap, MochiMedia, and GamerSafe were by far the most responsive of the bunch. HeyZap kept my game The Last Evasion in indefinite “awaiting approval”, so they can go fuck themselves.

It looks like a combination of services would be best, but that leaves you with HeyZap, GamerSafe, nonoba… and SocialGold, although SocialGold requires you to have complete control over the page your game is embedded in (ie you can’t post it on any portals) so that really isn’t much of an option (and you should read this thread that explains its serious security flaw).

In choosing the service(s), be sure to take a look at their developer forums and see how often they get answers too. Send them an email with some questions to find out how helpful they are. You can ask other devs about it, but my forum questions went unanswered. You’ll have a bit more luck if you are more sociable than me

Sponsorships

Sponsorships are an excellent choice, if you have a game good enough to attract sponsors. Just beware of bad/dickish sponsors. Be sure to read SteamBirds dev’s experience vetting sponsors on FGL and check out FGL’s informative 2009 report.

Remember that, besides FGL, there’s thousands of other sites that don’t check FGL that will be willing to sponsor your game with varying terms. Just shoot them an email and ask. You can charge more for one that requires you to completely re-brand your game, or for an exclusive (or time-sensitive exclusive) license to your game, or it could be as simple as putting in a logo somewhere and a link or two. Ask around, work out a good deal and see what happens.

Shareware

With the advent of Adobe Integrated Runtime (aka AIR) and tools like Sharify, we can actually package our games as downloadable apps that can be played on just about ANY platform (thanks to Flash Player 10.1, this includes Androids and holy shit TVs). While Sharify and similar services can lock your game, you can do that part yourself and just use an MTX service to handle the money part.

Ads

If your game is small and shitty (like my first one, and like the vast majority of Flash games), ads are a good option since MTX requires more time and skill implement. I’ve heard a few developers who have made a good amount of bank with ads, but they are few and far in-between. However, they do offer us a quick and easy way to earn (tiny amounts of) cash.

But there remains some pretty nasty problems with ads:

1. Clicks or impressions (whatever the ad provider does) provide a microscopic amount of revenue in the first place.
2. You get little more than half of the revenue generated by the ads. (Most do a 60/40 split.)
3. Each big-name portal has their own rules on which ads you can use.

Regarding that last one, as an example: you can’t show Mochi Ads on Kongregate; Newgrounds has their own ad system; Armor Games, the same. We have to make a different version of our games for each portal. This, my friends, is bullshit.

Conclusion

To get the most revenue from your games, you will need to decide what your business model is before you even write one line of code. Banking on the general goodwill of your audience? Use Flattr, add a PayPal donations button, and maybe an ad for a preloader. Have a multiplayer game? MTX is the way to go. Have an amazing single player experience? You’re probably better off with the shareware model. But in all cases, you should at least ask around for sponsorships, because the terms can be so flexible with good payoff. Also, don’t forget Twitter/Facebook/etc. share links!

So, all in all, I’m really happy to see people taking Flash games seriously and throwing some genuinely useful financial tools at developers. And as always, things will keep changing and we’ll see better ways to bake our cake and eat it too. Good luck and have fun!

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.

Let’s turn this around by asking this: would content be dead without the 3 Horsemen? The obvious answer is “No”. There will always be content regardless of whether or not there’s a way to monetize it. Why? Because humans have a fundemental [sic] need to create. It’s in our species’ best interest to create–it’s how we got to the top of the natural food chain and it’s how we’re going to stay there.

The sad news is that, even from King Content’s perspective, consumers are still at the bottom of the pile. For one, it’s because we will still make things even if nobody pays us to (and that’s still often the case, just take a look at any indie scene), so it doesn’t matter if consumers exist at all. However, I hope they’ll evolve into prosumers; that they actually become more useful in the grand scheme of things than just being “eyeballs”. I think we’re starting to see that trend with crowdsourcing and such–we just have to build the tools that can compile and analyze the data they create in their everyday lives as patterns. We also need to enable them to make meaningful decisions and connections in the things they do in order to steer content to the whims of the people. That way content producers can stay sharp by navigating the dynamic environment that is social trends and consumers will stay interested and support fresh content. I wanted to get into why we should be socially responsible by making content actually useful to people rather than mere consumables (you are what you eat!), but that’s a topic for another day.

I don’t understand why Creighton mentions microtransactions–which replaces ads quite nicely–and still insists ads are going to continue to fuel the heist, when they’re actually on their way out. The ecosystem won’t die, as he claims, but rather evolve, which is nice. Also, he groups TV networks into the meta-aggregator category, rather erroneously I think. They’re content producers with direct access to vast distribution channels (actual channels piped to TVs), which makes them a naughty mix of content producer and aggregator. I don’t think the meta-aggregator category even exists outside of things like feed aggregators like Google Reader as such, but I think that’s delving into the deep, dark caverns of semantics. So let’s just slowly step away from that one.

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.

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.

So my poor man’s method of making lines is done by interpolating the position of a particle from the previous to the current frame, for a total of 3 setPixel32() operations per iteration. (We can use setPixel() for a solid performance gain, but at a different kind of cost that I’ll explain later.) To give the particles a long tail we simply decrease the alpha of the particle bitmap a little bit every frame, making older particles fade more as time goes by. This means we can skip fillRect() to clear the bitmap every frame, but I’m wondering if that’s faster or slower than ColorTransform. Haven’t tested, for shame.

I’ll admit that I haven’t tried this method with bitmap-based particles but those would work just as well, in theory (using blitted rendering). One of my current projects demands those trailing things so I didn’t look into it. If you try it, please comment on this post below with your findings

particleMap.lock();
for (i = 0; i < _numParticles; ++i) {
  p = particles[i];
  // get our velocity from the perlin noise map
  vel = noiseMap.getPixel(p.x>>3, p.y>>3); // because noiseMap is 1/9 the size of particleMap
  var brightness:Number = vel / 0xFFFFFF;
  var speed:Number = 0.1 + brightness * p.speed;
  var angle:Number = 360 * (brightness * p.wander) * 0.0175; // roughly PI / 180 to convert to radians
  p.vx = Math.cos(angle) * speed;
  p.vy = Math.sin(angle) * speed;
  // absolute value for velocity calculations
  var pvx:Number = p.vx < 0 ? -p.vx : p.vx; // use bitwise sign flippage
  var pvy:Number = p.vy < 0 ? -p.vy : p.vy;
  // poor man's lineTo ENGAGED
  var nx:Number = p.x + (p.vx >> 1); // where we are now + half the distance to where we will be
  var ny:Number = p.y + (p.vy >> 1);
  var mx:Number = nx - p.x; // then half THAT distance for a third position...
  var my:Number = ny - p.y;
  // actually apply velocity to pixel
  p.x += p.vx;
  p.y += p.vy;
  // bounds-check
  if (p.y < 0) p.y = h - 1;
  else if (p.y > h) p.y = 1;
  if (p.x < 0) p.x = w - 1;
  else if (p.x > w) p.x = 1;
  // pick our color based on speed
  speed *= 60;
  if (speed > 255) speed = 255;
  color = 255 << 24 | speed << 16 | speed << 8 | speed;
  // render the particle three times, each in different places to get a line-ish thing going
  particleMap.setPixel32(p.x, p.y, color);
  particleMap.setPixel32(mx, my, color);
  particleMap.setPixel32(nx, ny, color);
  }
  // and we're done. release the pixels!
  particleMap.unlock(_r);

So that gives us some spotty-but-close-enough trails to help with our collision detection. It works like this: We create a single bitmap to use as a canvas for our particles. We render those particles using setPixel32() as mentioned above. Sprites will use this bitmap as a source for collision data. Every other frame or so (more on this later) the sprites will grab a section of pixels from the particle bitmap using something like getVector() (>= Flash 10) or getPixels() (< Flash 10), using their own position and dimensions for the sourceRect parameter.

shipVec = buffer.getVector(_rc); // get an array of pixels from the whole sprite
_rc.x = int(this.x); // change rect to particleBMD's coordinate space
_rc.y = int(this.y);
pixVec = _particlebmd.getVector(_rc); // grab an array of the same area of pixels that our sprite is occupying
var a:uint;
var i:int = 0;
buffer.lock();
for (i; i < _l; ++i) {
  _pval = pixVec[int(i)]; // first look at the particle's image for opaque pixels
  a = _pval >> 24;
  if (a < 100) continue;
  // it found an opaque-ish pixel, so let's see if there's an opaque pixel in the ship there too
  _sval = shipVec[int(i)];
  a = _sval >> 24;
  if (a < 100) continue;
  /* if we get this far then we have a collision because one
    * of the ship's pixels is overlapping a particle's pixel.
    * we're only going to collide with red-colored particles though */
  _pval = _pval >> 16 & 0xFF; // red channel extraction
  if (_pval > 100) {
    var px:int = int(i % w); // translate 1d array coordinate to 2d grid coordinates
    var py:int = int(i / h);
    buffer.setPixel32(px,py,0xFF4e88c9); // colliding pixels are painted on the top of our sprite in a cold blue-ish color
  }
}
buffer.unlock();

As you can see on line 133 and 136, each sprite has a block of pixels ready to examine on each tick. The sprite loops through that block and compares every pixel of its own with the pixels in the Vector it got. If there's a match (eg both pixels are opaque) then look at the particle's pixel in detail to see if it's the droid one we're looking for and record its findings.

So you can alter line 151 so that the sprites check for specific colors in the particle bitmap, like anything brighter than dark grey (which I did here, or anything with an alpha greater than 0.1 or... use your imagination I guess?).

Because grabbing a new Vector from the particle bitmap can be so expensive (depending on the size of the sprite), you can time limit the collection so it only samples the particle bitmap once in a short while. In the demo SWF above I sample it once every 100 milliseconds or so, which comes out to about 24 samples a second (given 25 milliseconds per frame at 60 FPS)... as opposed to 2400 samples a second. The casual human eye can't tell the difference but it yields a significant increase in performance. Most performance tricks I've learned are based are smoke and mirror stuff like this.

You can use setPixel() (no alpha) but you'll have to test for color--obviously for a color that isn't what the background of the particle bitmap is, so it's a little more tricky. It's also totally possible to use other sprites as particles as long as you blit them (using copyPixels() or setVector()) to a single bitmap that can be checked by other sprites that collide with them. If you don't know what blitting is, 8bitRocket has a good rundown (it's where I first learned about it actually).

And that's pretty much it. You can download the example files/source below.

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…

Below we define our dimensions grabbed from pixels (raw bitmapData from some loaded file elsewhere). We just want to analyze a quarter of the image, hence we’re dividing both dimensions by 2. We also instantiate the array (a fixed-length Vector) we’ll be iterating through:

var w:int = pixels.width / 2;
var h:int = pixels.height / 2;
var _l:int = w * h;
var _rc:Rectangle = new Rectangle(0, 0, w, h);
array = new Vector.(_l, true);

Awesome. Now somewhere else in the code (say, an update method) we want to assign a chunk of pixel data to the array so we can pick through them one by one:

_rc.x = pixels.x;
_rc.y = pixels.y;
array = pixels.getVector(_rc);
for (i; i < _l; ++i) {
  _pixel = array[i];
  var alpha:uint = _pixel >> 24;
}

Alright, looks mighty fine. We’re just checkin’ out the alpha value in those pixels, you know whatever. BUT WAIT. While we’re running this code, the values for pixels.x and pixels.y are changing because our source image is moving around the stage. And guess what? Without pixel snapping on, we’re getting floating point values for those coordinates even though they’re typed as ints. This wouldn’t normally be a problem but since we’re extracting other pixel data using those values, they need to be floored or else we’ll get the rounding error I discussed above.

So to fix this bitch we simply change lines 6 and 7 to:

_rc.x = int(pixels.x);
_rc.y = int(pixels.y);

…and viola, no more error. (I used int() instead of Math.floor() because it’s hella faster). So I hope that helped someone out there because I sure as hell needed it Good luck and have fun.

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).

An important thing to keep in mind is that Pixel Bender sees channels in the order described above (RGBA). This little detail cost me a bit of time because I’m used to AS3′s order of ARGB–the alpha channel is first in AS3 while it’s last in PB.

To use any of the built-in functions you simply call them as they appear in the reference doc: all(x); atan(x,y); etc., no Math calls like we have to do in Flash (this through me for a loop, lemme tell ya).

For those of you who use the shortcut operations like var i:int = foo < bar ? foo : bar;, then you'll be pleased to hear they're supported in PB too. Just about the only thing "Hydra" (formally the codename for Pixel Bender, now--I guess--the name of the PB Flash implementation) does not support is loops of any kind and their related break/continue statements. That last bit is bad because there are times when I want to stop the filter if a certain condition is met. You just have to design your logic to take this into account from the start.

That's the basics but take special note that shader.data is actually an array, so you can do some naughty stuff like iterate through some kinky data and set the input as shader.data['whatever'+i].input = kinky[i]. Also note that in order to set the input for a shader in AS3 you must set it to shader.data.vdipb.INPUT = inputImage where vdipb is the variable name you declared in the PB shader itself.

More performance tips

Turns out that after I converted my kernel from using boolean methods (like boolean4() etc.) to if statements, it consistently executed faster. I also got some fractional FPS increases by using the age-old optimization of putting real values (eg 1.2) in the evaluation statement instead of references (eg pixel.r). See the last blog I linked above for some other obvious and not-so-obvious performance tips.

PB math is much faster than straight AS3 math but it's slightly brighter (I wouldn't say it shines per se...) when it runs in asynchronous mode, which is enabled by using ShaderJob. You use addEventListener(Event:ShaderEvent...) and then run start(false) to put it in asynchronous mode (the param is waitForCompletion and it's already false by default). See Ryan's post for a great example of how the ShaderJob has to be setup (Squize's post, linked above, is an even clearer example).

Realtime use of Pixel Bender

Asynchronous mode

Reading the above linked performance tips for PB you, like me, might be thinking "OH MAN I can rule the universe with ShaderJob doing bitchwork like heavy collision solving" and you'd be totally wrong. You only have to set the input for a shader once, but you do have to create a new ShaderJob per computation of the filter every frame/tick. This is the depressing because ShaderJob takes a LONG time to start up and it, unlike the job itself, does use CPU from Flash's main thread--you do not get the asynchronous hotness until the actual job is started. And it is sloooooowwwww. Unless you're doing some serious number crunching or temporary special effect, you will not see a huge benefit from using PB in your game.

To be clear, ShaderJob works well enough for realtime usage but my experiments have shown that it's not fast enough to be executed every frame (unless you're SWF is running at 20 FPS or so). I tried to get it to fulfill my game's collision detection system by processing the entire map, but PB just couldn't handle the job. Still, I do recommend you try it (using Squize's recursive implementation) and see if it works for you. Just keep your hopes down

Synchronous mode

You can set ShaderJob.start(true) but if you're going the synchronous route, I suggest applying your Pixel Bender kernel by using the filter method. It starts up much faster than ShaderJob and doesn't have to be restarted every time you want to update the input. You do have to wait for it to finish processing before it will move to the next line in your code though, but as I mentioned above, PB math is a lot faster than AS3's Math library. So if you're doing something intense(r) like severe image distortion then PB is definitely worth a shot, but if it's just conditionals then you're probably better off in pure AS3 land.

Conclusion

Besides doing complex calculations, another place where PB would really help though is processing large (like 600 or 10000 pixels wide or bigger) images. It loops through each pixel faster than AS3 does. But remember that in AS3 you can do loops, so easily skipping pixels (using the continue statement) can result in some significant performance gains if you're not processing all the pixels in the input data (eg skipping transparent pixels). There's a lot of pro/cons so experimenting is, as always, the way to go (if you can afford it).

So there it is, all the info I wish was out there when I started learning PB (I can't stop thinking of Peanut Butter!). Hope some of it was helpful and of course I could be wrong about something (except about declaring input once, I've heard otherwise but in practice it worked fine) so please don't hesitate to correct me if so. Good luck and have fun