Forrest’s AS3 / Flash Blog

A while back, I wrote an article entitled, How much money I made from Ad revenue writing Flash Games. This post discussed how much I made from Google Adsense, hosting several of my games on my site. The amount of profit I made with this approach relative to the time spent writing the games was not good- only a few dollars. However, I have now tried a few other approaches to monetizing games that are much more worthwhile, and I will share some of the details here.

Most of my first batch of games were fairly weak, so I wanted to see what would happen with a game that had some solid effort and polish. To this end, I wrote Omega Tower Defense. I’m not sure exactly how many hours it took to write; I worked on it in my spare time for about two weeks.

This game is monetized in two ways. First, I signed up for a MochiAds Developer Account, and set up their pre-game splash ad. Second, there is a link to a site which I built recently to explore the publisher end of the Flash game business, FlashGameALot.com.

Lets look at the revenue from MochiAds so far.

The total is a little over $100 in a little over 2 weeks, for over 400,000 impressions. It looks like it is dropping off sharply at the end, but that is because the graph includes data for today, which isn’t complete. Implementing MochiAds was really easy- 30 minutes or so from start to tested.

FlashGameALot served over 4,600 unique visitors on its peak day, a few days after the release of Omega Tower Defense. I don’t have exact stats, but I think that most of these came from the link in OTD. I have Google Adsense on the game page on this site, and that is currently making around $1 / day (I can’t give exact details because it is against Google TOS).

I read the comments that people made about Omega Tower Defense and determined that there was plenty of room for improvement, then wrote Omega Tower Defense 2, starting from the original code and making several major additions and several minor tweaks. Building the sequel took about half as much time as the original.

There are hundreds of Flash game sites that will pay game developers to incorporate ads and links to their site into a game. Before writing Omega Tower Defense, I wrote another game, Magnet Golf. I attempted to find sponsors to license the game by visiting the most popular game sites, and laboriously filling out their submission forms. Most didn’t get back to me, and some took a long time. Eventually, I got an offer for $300, which I felt was too low, so I just released the game with no ads except a link to my site.

For Omega Tower Defense 2, rather than trying to find a sponsor the old fashioned way, I signed up at FlashGameLicense.com, which is a marketplace for game developers and sponsors. Adam Schroeder runs the site, and is very helpful and responsive to inquiries. It was easy to submit my game to their list, and within 2 weeks, I received several bids, from $300 to $1300 for exclusive sponsorship of the game. I settled on an agreement with FlashArcadeGameSite.com to exclusively display ads for them, as well as to display MochiAds under their account, for $1700. I was allowed to keep a link to my site in the game menu. Overall I feel that this was a pretty good deal. I might have made more in the long-term by displaying MochiAds under my account instead, but I am happy with a greater immediate payoff.

Conclusion
So far, I have written and published 10 Flash games. Based on my experience, the easiest and most profitable way to monetize flash games is to submit them for licensing to FlashGameLicense.com. MochiAds are a nice way to make some additional long-term revenue. It is much more effective to write one really good game than several mediocre games. If you write a game that some people like and others don’t, look at why some didn’t like it, and make a sequel- it will take less effort than writing a new game from scratch, and it is more likely to be a good game (unless your first game was already perfect).

ActionScript 3 can display a dynamically generated bitmap, in which the RGB values of each pixel are computed by code. Using this capability, it is possible to render 3D scenes, process video and images, and create other effects. To draw pixels to the screen in AS3, one creates instances of the Bitmap and BitmapData classes. The BitmapData represents an array of pixels, while the Bitmap is a DisplayObject that renders those pixels. In order to draw a dynamically animated bitmap, it may be necessary to write to every pixel in the BitmapData each frame. There are at least two ways to write to all of the pixels in a BitmapData- one is to call setPixel once for every pixel, and the other is to build an appropriatedly sized ByteArray, then pass it to BitmapData.setPixels (once per frame). So, if you want your code to run as fast as possible, which should you choose? I implemented and benchmarked 8 variations of these two approaches. The code, benchmarks, and results follow.

In each test, there is an 800×600 Bitmap, showing the same simple color animation. Performance is measured in frames per second, on my MacBook with dual 2 ghz Intel core dual processors, 1 gb ram, and Safari 3.0.4.

Buffer Test 1 - 20 fps (this is the fastest)
Run Test 1 Source Code: BufferTest1.as
The fastest of the 8 implementations calls setPixels once per pixel, uses y in the outer loop and x in the inner loop, and locks and unlocks the BitmapData before and after writing to it. The main loop of code looks like this:

outputBitmapData.lock();
for(y = 0; y < STAGE_HEIGHT; ++y)
{
  for(x = 0; x < STAGE_WIDTH; ++x)
  {
    r = (t*100 + 255 * x / STAGE_WIDTH)%255;
    g = 180;
    b = 180;

    outputBitmapData.setPixel(x, y, (r<<16) + (g<<8) + b);
  }
}
outputBitmapData.unlock();

Before we move on to implementations using ByteArray, let us consider a few variations of the code above.

Buffer Test 6 - 20 fps (loop order doesn’t matter)
Run Test 6 Source Code: BufferTest6.as
This test is the same as test 1, except the loops iterating over x and y are interchanged, so the the outer loop is over x, and the inner loop is over y. If this were C++, I would expect this to be slower than test 1, because it writes to memory addresses that are out of order. However, it doesn’t seem to matter in AS3.

Buffer Test 7 - 9 fps (make sure to lock and unlock before setPixel)
Run Test 7 Source Code: BufferTest7.as
This test is the same as test 1, except the calls to lock and unlock are removed. It is much slower than test 1.

That wraps it up for approaches based on calling setPixel once per pixel. Now, lets look at some implementations that call setPixels once, with a ByteArray.

Buffer Test 5 - 10 to 11 fps (best ByteArray)
Run Test 5 Source Code: BufferTest5.as

This is one of the best ByteArray based implementations that I came up with. The main loop for this test looks like this:

buffer.position = 0; // buffer is a ByteArray
for(y = 0; y < BUFFER_HEIGHT; ++y)
{
  for(x = 0; x < BUFFER_WIDTH; ++x)
  {
    r = (t*100 + 255 * x / BUFFER_WIDTH)%255;
    g = 180;
    b = 180;
    buffer.writeInt( (255<<24) + (r<<16) + (g<<8) + b );
  }
}
var rect:Rectangle = new Rectangle(0,0,BUFFER_WIDTH,BUFFER_HEIGHT);
buffer.position = 0;
outputBitmapData.lock();
outputBitmapData.setPixels(rect, buffer);
outputBitmapData.unlock();

Buffer Test 4 - 10 to 11 fps (writeInt vs writeUnsignedInt doesn’t matter)
Run Test 4 Source Code: BufferTest4.as
This is identical to test 5, except the call to writeInt is replaced with a call to writeUnsignedInt. There isn’t much change in performance here.

Buffer Test 3 - 6 fps (writeByte is SLOW)
Run Test 3 Source Code: BufferTest3.as
In tests 5, the call to writeInt effectively writes 4 bytes at once. It is also possible to call writeByte 4 times instead. Note that each 4 byte block in the ByteArray represents a pixel, in ARGB format (yes, A comes first). So this is the sequence of calls to writeByte to output 1 pixel:

buffer.writeByte(255);
buffer.writeByte(r);
buffer.writeByte(g);
buffer.writeByte(b)

This approach is much slower than calling writeInt or writeUnsignedInt. I think this is because of the overhead of the function calls (and maybe because ByteArray is doing some internal index calculations that aren’t necessary).

Buffer Test 2 - 9 fps (ByteArray’s operator [] is fast)
Run Test 2 Source Code: BufferTest2.as
Calling readByte and writeByte is one way to get and set the data in a ByteArray, but one can also use the [] operator, which is faster. In this test, my code keeps track of the buffer offset for the current pixel / color channel (rather than in the previous tests, where this position is buffer.position, and is internally managed by ByteArray). Here’s the main loop for this test:

buffer.position = 0;
var offset:int = 0;
for(y = 0; y < BUFFER_HEIGHT; ++y)
{
  for(x = 0; x < BUFFER_WIDTH; ++x)
  {
    r = (t*100 + 255 * x / BUFFER_WIDTH)%255;
    g = 180;
    b = 180;

    ++offset; // skip alpha channel
    buffer[offset++] = r;
    buffer[offset++] = g;
    buffer[offset++] = b;
  }
}
var rect:Rectangle = new Rectangle(0,0,BUFFER_WIDTH,BUFFER_HEIGHT);
buffer.position = 0;
outputBitmapData.lock();
outputBitmapData.setPixels(rect, buffer);
outputBitmapData.unlock();

Buffer Test 8 - 9 fps (locking doesn’t matter for ByteArray)
Run Test 8 Source Code: BufferTest8.as
This is identical to test 2, except that the calls to lock and unlock around the single call to setPixels are removed. The frame rate does not change, indicating that there isn’t any benefit to locking in this case. I think this is because most of the time is spent getting data into the ByteArray, not copying it into the BitmapData with setPixels.

Conclusion
The fastest way that I have found to draw pixels in AS3 is to call setPixel once for each pixel, making sure to lock and unlock before hand. If you know of a faster way, please tell me about it!

These tests imply a fairly severe upper bound on the performance that can be expected for per pixel rendering in Flash. In any real code, frame rates will be lower than those reported here, because there will be more work to do to compute the RGB values for each pixel (in these tests, the values are calculated trivially).

One of the most interesting uses of drawing pixels in AS3 is 3D rendering. As far as I know, there are a few 3D engines in AS3 that uses per-pixel drawing, including my real time ray tracer, and Away3D. On the other hand, the mainstream engines Sandy and PaperVision3D, do not rasterize into pixel buffers, but instead achieve higher performance by hacking Flash’s capabilities to draw scaled and rotated textures (which are not ideally suited for use in a 3D triangle renderer).

However, there are still other options available to make drawing pixels faster. For example, this thread on FlashKit describes a method of drawing pixels in a palletized color mode. This reduces the memory required per pixel from 4 bytes to 1 byte, but comes at the cost of restricting the number of colors on screen to 256 (+ other effects on top of that). HaXe may provide another possible avenue for accelerating per-pixel rendering in the Flash 9 virtual machine, as it is possible to program in Flash’s bytecode assembly language.

Inspired by the TinyGP programming contest, I wrote my own small implementation of genetic programming in C++. Then I ported it to ActionScript 3, and put together some demos which illustrate what genetic programming does. The source for the library and demos are available in AS3 and C++.

I was amazed at how easy it was to get access to the raw pixel data coming in through a video camera with Flash (compared to doing it in C++). In only about 200 lines of code, I was able to put together this real time edge and motion detector. The source is available.

Here’s a simple demo of a 3D spinning cube in AS3, written without any libraries such as PaperVision or Sandy. The source code is available, and includes a fairly useful 3D vector class.

I wrote a real time ray tracer in AS3. Follow the the link for a demo. The page contains a discussion of the optimizations that I applied to bring it from running at 4fps to 30fps. The AS3 source code is included. I also ported it to C++ / Mac OS X / OpenGL (which runs in real-time at 640×480), and the source is available for that as well. There is a fairly extensive discussion on reddit about this code. Someone also successfully compiled it for GNU / Linux, and described the process there.

**Update**
Sometimes the archive.org files are not available. You can still get low-res versions here (still better than the one’s on YouTube).
——

While developing MagnetGolf, I recorded my screen and narrated the process. This series of videos on developing a game in Flash 9 and ActionScript 3 is now available in its original high quality on archive.org. Here are links to the video files (right click and download them):

Highest Quality MOV, Parts 1 - 5
Highest Quality MOV, Parts 6 - 10
Highest Quality MOV, Parts 11 - 17

Archive.org download page (has other formats)

I am pleased to announce FlashGameALot.com, a flash games directory that offers 50-50 ad revenue sharing with developers (much like GameGum and Kongregate). If you have written a flash game, submit it to this directory and get some extra traffic and ad revenue.

I wrote a few more flash games since my first batch. Here are links to them:

• Magnet Golf
• Tower Defense 3D
• How many of the first 1000 primes can you name in 3 minutes?

I am conducting an ongoing experiment to see how much money can be made from advertising with web games written in Flash. There has recently been some talk about this subject, as the developer of the Flash game Desktop Tower Defense reportedly made profits that would amount to over $100,000 per year (if the game were making that much money for a whole year, which I don’t think it has been). Encouraged by this result, I wrote several games and promoted and monetized them in various ways. In this post, I give an account of what I wrote, how I advertised and monetized it, and how much money I earned as a result.

The Games

First, lets look at the games that I wrote:

Cave Flyer 1.0 - this was the first game I wrote for this experiment. It is based on the simple concept of flying through an ever-shrinking cave in a ship with lots of vertical inertia. It took about 4 hours to write in ActionScript 3. The graphics are weak, and it doesn’t have a high score list. Nonetheless, it is a fairly classic concept without many Flash competitors (I think because it would have been hard to write efficiently in ActionScript 2), and people seem to find the game play fairly enjoyable.

Magic Plant 1.0 - this started out as as simple animation, and then i tried to add a game mechanic to it, which turns out to be too easy to be interesting to most. On the other hand, it has a certain zen charm that is strangely appealing, and while some people hate it, some like it. It requires patience, at least. It took about 4 hours to make.

Space Miner 1.0 - after seeing people’s reaction to the somewhat weak Magic Plant, I decided to try my luck with a game which had a fun mechanic and a reasonable amount of effort in the graphics. The gameplay is based on the classic crystal catastrophe, although it is somewhat less diverse. I think I enjoyed this game much more than most people who played it, as I understood how deep and insanely hard it gets by level 20, and was able to get that far. Most people seemed to get bored because the first levels were too easy. This one has an online high score list- my hope here is that it encourages people to play again and again to beat the high score. But sadly, I hold all of the top 10 scores. This game took about a 3 days to write.

Xonf 0.9 - this game is pretty sweet in my opinion, though very hard. It has a pooled particle system that avoids triggering garbage collection, which can be an issue in smooth animation with ActionScript 3. The gameplay is taken from Mars Matrix, a hardcore overhead shooter that consumed many hours of my college years, as it was on an arcade machine right next to my room. So I had been planning on writting a game with Mars Matrix mechanics for a while… another idea that has been in the works for a long time, and which I was happy to work in here, is the procedural generation of bodies and flight paths for the enemies. Golan Levin’s walking things is the inspiration here- he used flash to generate random walking insects. It seemed to me that this was a natural way to construct critters for a game. Spore, the game by Will Wright, is heavily influenced by the same idea. This also has a high score list and other people beat my score. Some people really like this game, and others don’t, often complaining that it is too hard. I rewrote this game from scratch 3 times to optimize the particle system, so it wound up taking about 2 weeks, on and off.

How many elements can you name in 10 minutes? - Seeking inspiration for an easy game to write that would be popular, I looked at the most dugg games in Digg’s Web Games Section. How many states can you remember in 10 minutes and similar games were very popular, and seemed pretty simple, so I wrote my own variation on this theme. It took about 45 minutes to write.

Spreading the Word and Monetizing Page Views

Those are the games. Now lets look at how I distributed and monetized them.

First, all of the games are hosted on my site, in a section for original flash web games. This is just an index of all o fthe games, with thumbnails and links to a separate page for each game. On the page for each game, there are two Google Adsense skyscraper format ad blocks. For some of the pages I used only text, and others text or images (I think that image advertisements are more appropriate for games, than, say lectures on economics). I will go over the Adsense data in the next section.

To promote the links to the games on my site, I submitted each of them to Digg in the Playable Web Games section. I also bookmarked them on my delicious account.

In addition to hosting the games on my site, I uploaded them to Kongregate and GameGum, both of which are flash game portals that offer ad revenue sharing with developers. To direct some of the traffic to my games on these sites back to my own site, I put a link in the games themselves back to the index of webgames on laserpirate.com.

Results and Data: How Much Money Did I Make?

So, how much money did I make from these games? First lets look at the page impressions and other related data. Google’s Adsense terms of use prohibit me from giving away specific information about # of impressions, click through rates, etc, so I will be vauge: For these games, I got somewhere between $1 and $10 of revenue from Adsense impressions. I might also note that GameGum’s revenue sharing system (allegedly) works by showing your adsense ads some fraction of the time on their site, although I’m not convinced that it works. If so, I think that those adsense views are not included in this total.

I can also give data on page requests from my own server logs, but the reader should be aware that these do not directly correspond to Google impressions, because they include non-unique views, many of which came from me during developement- and probably for some other reasons too (so Google: please don’t smite me, I’m not trying to break any terms of conditions).

For the months of July and August, the number of requests to my server for each of the games was:

The elements - 261
Cave flyer - 89
Magic plant - 83
Xonf -101
Space miner - 142

We can also look at viewing statistics from GameGum and Kongreate. The stats for GameGum are (in # of impressions):

The elements - 18,091
Cave flyer - 198
Magic plant - 83
Xonf -201
Space miner - 121

I am find the count for the elements game to be quite dubious. If you refresh on the GameGum site, it count as another impression, so maybe someone repeatedly refreshed. I don’t think I got adsense impressions for that many views, which suggests that they were not unique.

Here’s the data for Kongregate (they provide statistics in ‘Game Plays’ and ‘Ad Impressions’; these listing are ad impressions):

The elements - 1169
Cave flyer - 1263
Magic plant - 545
Xonf -1021
Space miner - 821

This totals to 4819 impressions, for which Kongregate lists a revenue of $0.51. This means that that are paying about $0.10 per thousand ad impressions.

It is also interesting to look at the number of times each game was dugg:

The elements - 11
Cave flyer - 3
Magic plant - 1
Xonf -2
Space miner - 1

From these numbers, we can see that my recipe of “take a popular game on digg that is easy to write and clone it” seems to have worked pretty well for the elements game. Digg didn’t show much love for the other games.

Now lets look at some overall totals:

Time spent writing games: a few hours a day over 3 weeks
Games written: 5

# of views of those games on my server (not to be confused with Google Ad impressions): 676
Amount of money earned with Google Adsense: between $1 and $10

# of view on GameGum: 18694
Amount of money made with GameGum: I’m not really sure. I looked at the HTML they generate to be sure that it serving my ads, but I can’t see any evidense of them being served in the adsense reports.

# of views on Kongregate: 4819
Amount of money made with Kongregate: $0.51

Conclusion

As this data shows, it is entirely possible for Flash web games to return very little profit, compared to the amount of time it takes to write them (except for the elements game, which shows that copying whats popular and being lazy is effective). I certainly would have made more money if I had spent that time writing software for my employer. But if I spent 45 minutes writing the next Desktop Tower Defense, that might be another thing. It is worth considering that none of these games are truly polished like Lumox 2, so I am not at all surprised that some people found them mediocre. It would be interesting to see how this goes with a game that has excellent graphics, sound and gameplay. It takes a lot of work to write such games. Maybe more work than it is ecconomical to do. On the other hand, really high quality games are often sponsored for $100-$1000. I will probably still write a few more web games just for the fun of it, but I won’t really expect to make any significant amount of money. In contrast, my shareware titles such as Lumox 2 and Ultragroovalicious have sold many copies, producing a very reasonable return on my time investment for writing them. Seth Godin said something like “it is better to try to sell a product that costs $100 to 10000 people than one that costs $1 to 1000000 people”. We can view the web gaming market as something like trying to sell a product that costs $0 to infinity people.