First and foremost, flexwires should now be compatible with Flex 4. It still targets Flex 3 and uses the Halo theme, but that shouldn’t stop you from using it within a Flex 4 app now. Secondly, flexwires should be working properly in Adobe AIR now too. Flex’s drag-and-drop works differently depending on whether it’s running in the browser or if it’s in an AIR app, which I didn’t know before. That’s fixed now, and you should properly see placeholder wires while dragging now.

There’s a new flexwires 1.1.0 ZIP to download over at github. The SWC inside is built with the Flex 3.5 SDK, but you should be able to include it in a Flex 4 project without any issues.

To succeed, to knock Flash off it’s throne as the strongest innovator in web technology, HTML, CSS, and JavaScript need to be pushing out new versions much faster. When did HTML4 come out? Not in this decade. Consider the way everyone has been talking about HTML5 and CSS3 so much lately. I’ve seen so many cool examples that show the improvements over HTML4 and CSS2. To me, it seems like most of the big decisions have already been made. Yes, it may be a while before the standard is officially approved, but the important stuff is there and browsers are implementing things like mad. That’s so awesome!

With that in mind, I strongly suggest that we all should begin thinking about the next versions of Open Web tech very, very soon. You know why? Because Adobe generally has an 18 month release cycle for many of its products. Flash Player will continue to improve with cool new features, and that’s what keeps developers like me sticking with Adobe’s infamous plugin. I’m not saying that HTML needs the same duration for a release cycle. Standards are finalized at a slower pace for good reason. However, I strongly believe that HTML and all of its open friends have been stagnating for far too long, and that the release cycles have been slower than they should be.

Every browser vendor has been committing to new features like crazy lately, and many have been inventing new APIs that greatly improve the web. Keep that up, guys, because I’m impressed. However, I think one extra bit of effort should be combined with all this new stuff. Start throwing things into a bin that will eventually become HTML6, CSS4, and ECMAScript 6. Maybe not immediately, but I think 12 to 24 months from now, the most interesting features of the upcoming Open Web should be considered ready for the majority of smaller websites, and six months away from appearing on major web portals. At that time, developers should be just as excited about HTML6 and other future tech as they are today about HTML5.

I’m a Flash developer, and I’ve been one for nearly six years. I love Flash, and I hope that it continues to improve for a long time to come. However, I understand the role of the open web, and I want to see it follow a similar path. I do not see any sort of epic opposition between Flash and standards. In fact, I think that plugins like Flash Player and Silverlight can help to drive standards by being a test bed. Still, I see excellent opportunities for more friendly competition between plugins and web browsers, much like browsers compete among themselves to provide the best user experience for visiting our favorite websites. However, even with all the passion that has recently grown within the Open Web community, I think that there’s a chance that everyone could all settle down again and leave those technologies in limbo for a while. That would be unfortunate, and I encourage anyone who supports the idea of an Open Web to advocate for quicker standardization and to push for continued innovation in the very near future.

Recently, the folks at Adobe gave me access to early builds of AIR for Android. With permission, I’m able to share a little bit about my experience so far. For your enjoyment, I’ve also uploaded a couple of videos to YouTube where I demo Chroma Circuit on the Motorola Droid along with Gridshock and Qrossfire on the Google Nexus One.

First, here’s a look at Chroma Circuit:

Since I’ve only been targeting a single platform so far, I hadn’t yet spent a lot of effort making my games resolution independent. With each one, I had to spend a couple hours making adjustments to ensure that the layouts would properly fit the screens of different devices. None of this new code that I wrote is Android-specific. In fact, now that my games have these changes in place, I shouldn’t need to make any adjustments when Adobe brings AIR to other types of smartphones in the future. That’s awesome. Of course, if a platform has an important UI paradigm, like Android’s hardware back button, then yes, I’ll make the necessary tweaks to ensure it is supported.

Now take a peek at Gridshock too:

Performance-wise, AIR for Android is fast. When I was making iPhone apps with Adobe’s Packager for iPhone in Flash CS5, I had to make heavy use of hardware acceleration to make even the most basic animations run smoothly. On Android, my games are all rendering in software, and they feel no less responsive on the phones than they do on my desktop. As Lee Brimelow pointed out, “[Adobe is] able to get tremendous performance on Android devices because Google and the various handset manufacturers have chosen to work closely with us to provide the best possible experience to the end user.”

Finally, here’s my third game, Qrossfire:

With barely any work on my part, I got my three existing mobile games running in AIR for Android. It’s exciting. This week, I’ll be starting a totally new game (finally!), and I plan to target my Android phones first. It’s a side-scrolling shooter, which is a nice change of genre for me, and the control scheme I have planned should be fun to implement with multi-touch.

As soon as I received the first request from a color blind user who was having some trouble with Chroma Circuit, I realized my mistake in simply choosing an aesthetic mix of colors that looked good to my own eyes. Only a couple of the colors seemed similar to the color blind player, but those were enough to take all the fun out of the game, and to make it mostly unplayable. Right away, I started putting together a new palette for Chroma Circuit. I’m no expert in this area, but I do have some tools at my disposal that certainly helped me out.

I think the first thing I did was take screenshots of a few levels from Chroma Circuit to load into Photoshop. Under the View menu, go to the Proof Setup sub-menu. This section lets you preview how your image will look in different color modes. For instance, designers can try CMYK to see how something might look a little different in print. You’ll find two options relevent to color blindness here, Color Blindness — Protanopia-type and Color Blindness — Deuteranopia-type.

A standard spectrum of hues is shown above. Each of the color blindness proof options is shown for comparison. If you have a moment, and want some more examples, grab screenshots of your favorite websites that use an interesting mix of colors, paste into Photoshop, and take a look at how they change for color blind visitors. Below, you can see Chroma Circuit through the eyes of someone with Deuteranopia-type color blindness. The top half displays a level with the original colors, and the bottom half shows the same level after I made changes to the palette.

To address the issue with Chroma Circuit, I took a pretty basic approach. I bumped up the contrast among each level’s colors as high as I could so that players could rely on brightness, in addition to hue. I generated the brightness levels based on the number of colors appearing in the level to achieve maximum contrast. If there were four colors required, I might set brightness values to 20%, 40%, 60%, and 80% brightness. If there were only three color needed, I would use 20%, 50% and 80%. The resulting colors weren’t particularly pretty, but they seemed to work well enough for the players who thanked me after I made the change (accessible in the Settings screen).

When I brought Chroma Circuit to mobile devices, I decided to take a different approach based on a suggestion from a color-blind player. Rather than creating a palette of high-contrast colors, I decided to augment my regular palette with a set of unique patterns for each color, if “Pattern Mode” is enabled.

With Qrossfire, another puzzle game I made, I tried adding something directly to the game, rather than making players enable it from the settings screen. In addition to colors, I created a set of visually unique symbols to display on the game board.

In my most recent mobile game, Gridshock, I went back to making the patterns an option. Still, I feel like I integrated the patterns into the overall design better because I often “forgot” that I had the patterns enabled while testing. Additionally, Gridshock provided a new challenge that I think may have actually helped me design the patterns better. Since the timer bar shows the current color, and it’s a different shape than the squarish blocks in the grid, I had to ensure that the patterns were bold and flexible enough to display within differently-sized regions.

More Real-World Examples

Let’s take a look at some other games out there, including popular commercial titles to see how they handle (or mishandle) colors.

As I was writing this post, I was lucky to came across some complaints about BioShock 2, an example of a big commercial game that isn’t friendly with colors. Negative Gamer shows us What BioShock 2′s Hacking Looks Like if You’re Colour Blind.

Ars Technica had an article about the developers being unaware of color blindness a couple years ago. It includes the Puzzle Fighter screenshot comparison above, and many other examples described in the text, including first-person shooters, platformers, and more. Notably, New Super Mario Bros. doesn’t provide enough visual cues to easily tell the difference between Mario and Luigi.

In Bejeweled, each gem not only has a different color, but a different shape as well. These shapes are integrated into the design, and they’re always on by default. Instantly playable by color blind gamers!

I know, I know, it’s not a video game, but standard playing cards are an excellent example of game pieces that can be used by color blind players. Though card games often rely on the difference between red and black suits, color blind players shouldn’t have a problem with that. You might have never noticed, but both red symbols (hearts and diamonds) come to a point at the bottom while the black symbols (spades and clubs) have that little flat handle. Moreover, the contrast between red and black should be more than enough to allow players to note the difference, even if red looks a little more brown or yellow to them.

Don’t ruin the fun!

We all hate when players to stop having fun in our games for any reason. Though we might not be able to make changes to support all disabilities, ones like color blindness are often very simple to address, and I think it’s worth the small amount of effort required. One needs not ruin the aesthetic experience to make it happen either. If you can integrate various helpful tweaks into your main design, great, but a simple setting that can be enabled only when needed can be an acceptable alternative. Don’t forget that Photoshop provides tools that can be a big help in the process.

If you can, try to remember color blindness early in the design process, so that you don’t have to spend time changing an existing design that you might already be happy with. Not only will it save you frustration, but it might allow you to find better solutions that might not be acceptable later in the process.

The original post follows, in its entirety:

My most recent mobile conversion, Gridshock, has gone live in the iPhone App Store. Unlike Chroma Circuit, Gridshock required some heavier fundamental layout changes, but I think I kept the difficulty balance and speed at a level that’s about the same as the original. I even took some time to add a couple new features.

First, I added the Shock powerup to the mix. When you match five or more lights, one of them won’t disappear. Instead, it upgrades to add the powerup, and it can be matched again. When matched a second time, it will remove an entire row of lights. Very useful when things get fast and frenzied, and the grid has almost overflowed.

On the Options screen is a new setting called “Patterns”. For players who might have difficulty telling the difference between some of the game’s colors, Patterns mode adds a unique and high-contrast shape to each color.

What’s that I said about Android?

On other fronts, you might be interested to know that I’ve had a chance to preview an upcoming version of Adobe AIR for the Android mobile operating system. Adobe’s Ted Patrick recently showed off a few sneak peek Android screenshots, and he includes both Chroma Circuit and Gridshock in the mix.

The only thing I needed to focus on for Android from a development perspective was ensuring that my games would fit well in different screen resolutions. Christian Cantrell’s recent article, Authoring mobile Flash content for multiple screen sizes, has a wealth of information on this subject, and I suggest any Flash developer expecting to target mobile check it out. I was thinking about writing a blog post about multi-screen content myself, but Christian covered all the details I would have, so I recommend it highly.

Watch the video above or over at Adobe TV. Now, if you’ll excuse me, I have a couple other mobile games to hurry up and finish.

Time Breakdown

To start, let’s look at the time I spent on various projects in 2009. Unfortunately, it wasn’t all fun and games. Though I had a decent savings to get me started, I needed to refill my treasure chests mid-year, and that meant time away from game development. Here’s a pie chart to visualize the breakdown:

As you can see above, I spent six months working exclusively on my own games full-time. For a month and a half, I worked on some contracts that involved developing games for other people (the next best thing to working on my own games, I suppose). In addition, I spent another four months on contracts building some Flex RIAs (non-game development, obviously). Finally, I took a couple weeks off in December to relax and enjoy the holidays.

As we take a look at my income next, please note that I will omit the amount I earned from things other than developing games. I want to focus more on what I earned specifically as a game developer rather than as an RIA developer. Regardless, I’ve mentioned this additional income because many game developers take the same approach: contract work funds the things we really want to do. Though I won’t give you specific numbers about the non-game income, I will note that well over half of my overall income this year falls into that bucket. In short, games did not pay the bills this year.

Quick Income Breakdown

In total, games earned me $29,413 USD in 2009. This year, I had five sources of income from games: primary sponsorships, non-exclusive licenses, advertising, iPhone game sales, and custom game development for clients. I’ll explain each of these below, for those who might not be familiar. However, let’s start with a simpler comparison to make one important point.

As you can see from the chart on the left, about 58% of my game-related income came from contract work. Once again, even focusing specifically on game development, we can see that contracting is still where the real money is. Big clients pay big money to bring in developers to get their projects done. For comparison, the chart on the right shows the amount of time I spent on each. As you can see, the majority of the income from games comes from only 20% of the time I spent on them. If I were only interested in the size of my paycheck, I think it should be obvious which type of work I’d want to choose.

Detailed Income Breakdown

Now, let’s go one level deeper. The games I built entirely under the Bowler Hat Games banner earned me $12,413 in 2009 with six months of work. Assuming I didn’t live in the San Francisco Bay Area, I might have been able to stick to games the whole year with only a small loss, hoping to make up for it as revenue continues to grow in 2010. However, my current location is pretty expensive, so focusing on my games exclusively is still not possible yet.

The majority of revenue comes from primary sponsorships, which are sold to game portals who want their branding and links to appear in any distributed version of a game. Sponsorships help them bring traffic back to their sites. They usually pay an author a lump sum for this privilege. Sometimes, sponsors offer performance incentives so that very popular games can earn more, but usually, a sponsored game only earns money from the sponsor once. I found this form of revenue useful to start out, but I’m not sure how often I will pursue it in the future. I’m starting to feel that they make it harder to build my own company’s brand because my games promote the brands of others so strongly.

Next in line is the non-exclusive, site-locked license, which allows game portals and virtual worlds to customize a game by adding their high score APIs, removing advertising, and making other small changes. By getting the game site-locked to one website (in other words, no distribution), they can offer a quality game directly on their portal for a lower price than sponsorship, but without the audience reach that a sponsorship offers. A non-exclusive license can earn as much or more than the primary sponsorship in the long run because you can sell as many licenses as you want. Generally, it only takes 2-3 hours for me to whip out a customized version of one of my games, and I earn more per hour for this work than what a primary sponsorship gets me for the original game.

By the way, FlashGameLicense.com provides an excellent service for Flash game developers to connect with publishers and sell sponsorships and licenses. I found primary sponsors for all three of my games there, and many of the portal owners that made non-exclusive deals with me initiated contact on FGL.

Often, advertising earnings can be a pretty low percentage of a game author’s revenue. However, my game Gridshock has found itself among the top games on the popular MindJolt portal (and Facebook app) for some time now, having received over 16 million plays overall as of the time of this writing. My all-time eCPM for all three games combined right now is $0.26 from MochiAds, though I’m showing a custom ad in Chroma Circuit right now to promote the iPhone version so that’s not earning anything at the moment. Gridshock alone is a tiny bit higher, at $0.28. I also use Google AdSense on the Bowler Hat Games website for some extra ad revenue, but their Terms of Service are mean, so I can’t really share anything about that.

Finally, there’s my iPhone game. I released it in October, and, as you can see, it hasn’t brought in much revenue, relatively speaking. The App Store isn’t an easy win these days, and that’s pretty much what I expected. However, Chroma Circuit has always done a little poorly compared to my other two games (other than the larger-than-average primary sponsorship), and that means I expect those to do better in the App Store once I finish polishing them up for the iPhone. If the iPhone version of Chroma Circuit had been released much earlier in the year, that percentage would have been higher overall, so I’m not ready to say that iPhone development isn’t worth the effort yet. Plus, it’s been a lot of fun learning to optimize for a mobile device and developing with a touch screen, so I’m happy to explore this area more in the coming year just because I enjoy it.

On to 2010!

As I noted above, my earnings as an indie game developer are pretty low in comparison to the salary I used to earn (and what I still earn as a part-time independent contractor). However, I’ve seen steady growth throughout the year from game-related revenue, and I’m expecting that growth to continue into my second year. I don’t know for sure how many months I’ll be able to focus on my own games exclusively in 2010, but it should be at least six again. Hopefully more!

My main goal for this coming year is to explore new sources of revenue. The mobile games space still deserves some of my time, and that will likely include more devices than the iPhone, if they don’t require too large a commitment. Should Adobe offer Flash Player 10 (I’m not interested in Flash Lite) on a device, I’m more likely to play with it. I’m also looking to explore micro-transactions. From what I’ve seen, games that use MochiCoins seem to do pretty well with players (though some portals seem to dislike them), and I definitely want to try adding them (or maybe another service, like GamerSafe or Heyzap) to some totally new games I have simmering in the back of my head. Desktop versions of my existing games are certainly a possibility too. Who knows if I’ll get around to all of that, but I will say that I definitely have a barrel full of ideas for the future of Bowler Hat Games.

The original post follows, in its entirety:

Head on over to the iTunes App Store now, and support your favorite indie game developer! Chroma Circuit can now be purchased for the iPhone and iPod Touch. If you’ve played Chroma Circuit before, get ready to experience new touchscreen controls, slick new graphics, and a total of 30 puzzles to solve. That’s 12 more levels than the original web version, plus some remixed levels that better fit the iPhone’s screen.

Alright, with the sales pitch out of the way, let’s get into the nitty-gritty details. First of all, yes, Chroma Circuit is built with Adobe Flash. It’s not Flash Player, though. This is a native app with the ActionScript compiled down to ARM assembly. You can read more about the details in the press release, Adobe Opens iPhone to Flash Developers (which has a quote from me!), and on the Apps for iPhone section of Adobe Labs.

Of course, what everyone’s been waiting for is, what do I think about it? Personally, I absolutely love this technology. I spent a few weeks with Objective-C earlier this year, trying to do a port of Chroma Circuit. I started getting the hang of the language and tools pretty fast, but to be honest, I wasn’t a fan. Too much memory management. Drawing and animation APIs that were a pain. It just wasn’t for me. I kept an interactive prototype of Chroma Circuit sitting around for months without any updates. Then Adobe asked me to help them bring Flash to the iPhone, and I had a more complete prototype within a couple of hours because I could reuse my existing code from the web version with very minor tweaks.

Optimization

Currently, iPhone native apps built with Flash are obviously slower than typical native apps, especially on older phones. The bottleneck, much like in the browser, is the software renderer. I think I’ve seen some speculation that because ActionScript is traditionally an interpreted language that it’s probably very slow when pre-compiled. That’s simply not true, and unless you write crappy code, it won’t be your bottleneck. Adobe has said that they’re using the same software renderer as their browser and desktop runtimes because it keeps things visually consistent. I like that, and I’m excited to see optimization to make it run better on less-powerful devices. Hopefully, that optimization will make its way back to Flash Player itself—much like what’s already happened with Flash Player 10.1—and that it will help push the community to innovate more.

Of course, optimization is not all on Adobe’s side. The fact is, most of us write code that is “good enough” to run on modern desktops. For a mobile device, optimization is more important, and I’m working hard to ensure that future updates to Chroma Circuit run better. Though I haven’t started using the new hardware acceleration feature, cacheAsSurface, I have spent time simplifying some of my graphical effects (which don’t need to be so detailed on such a small screen), ensuring that vectors don’t get redrawn unnecessarily, and making some display list manipulations (like depth changes) more conditional. For the original version, I focused mainly on removing bitmap filters (either completely or replaced by PNGs) and turning static vector art like backgrounds into bitmaps. Both helped quite a bit, and that’s the best I could do with a looming deadline to get it into the App Store in time for Adobe MAX. Now that I have more time to focus on polishing, I can explore and discover new ways to make the game run faster. Again, while I want to see more performance coming from the renderer itself, I certainly am not denying the fact that part of the job is my own.

The Future

What’s coming next? More features and better performance in Chroma Circuit, of course. My other games, Gridshock and Qrossfire, will be getting the iPhone treatment too. Making iPhone games isn’t my sole focus, though. The App Store is not a gold mine, and probably hasn’t been since people started calling it that. Instead, iPhone apps will be just one part of my revenue. Licensing, advertising, iPhone apps, and probably more. Adobe’s Shibuya looked pretty cool. Maybe I’ll make some AIR desktop versions of my games too. Certainly, there are new games simmering in my brain, and I’m sure you’ll see those hitting portals and making their way to iPhones and desktops as well.

That’s the focus of what I call “phase two” of Bowler Hat Games. I want to explore more revenue sources and discover a good mix that will help me reach my financial goals for the business. With the retroactively named “phase one” coming to a close, I hope to share with you a blog post with some charts and analysis showing the breakdown of revenue so far. I haven’t compared all the numbers yet, except to ballpark it all in my head, so I’m pretty excited to get down and dirty with the data.

What do we need?

It’s a very straightforward question, but you might be surprised about the answers. You’ll get serious answers about things that slow people down and make it hard for them to do their job. You’ll get inspiring answers about features your products or services may benefit from in the future (maybe even things people might be too scared to suggest in real meetings). You’ll get funny answers about how someone wants “weapons-grade plutonium”. In all cases, you’ll get useful results and engage the people around you. You’ll probably get more than answers, though. The most fascinating phenomenon is that people will start having conversations. Bob will read another Alice’s answer, then comment on it with his own thoughts with a little arrow pointing to the original.

I’ve seen the happen at two companies at which I’ve worked. At one, I was a full-time employee, and at the other, I was a contractor. In both cases, the message board instantly caught on, without explanation. One day it appears, and people instantly get it. In one case, it wasn’t a whiteboard. Nothing was provided for writing an answer. It was just a big thing on the wall with a permanent question (I don’t remember what exactly, but basically, “what are you up to?”). By day two, a clever individual had figured it out, and his or her answer materialized on a post-it. A conversation thread on the board became a cascading line of yellow squares. A couple weeks in, pictures of team members doing fun stuff were taped up there, and it was a great success.

Many business focus engagement so strongly on customers, that a little extra effort to engage employees can be surprising and exciting. A whiteboard or something else that asks a simple question brings a light-hearted atmosphere to the office and it may give you some information about what’s happening behind the scenes that was otherwise hidden. As someone who has experienced this addition to an office environment twice in my career, I highly recommend it for every business.

Qrossfire’s Title Screen

With Qrossfire, I spent some extra time creating unique art and graphics. Color, in particular, played a big role in giving Qrossfire the personality it needed and the quality of gameplay I wanted. I tried to pick strong primary colors with heavy saturation, in a balanced set of brightness levels. With both Chroma Circuit and Gridshock, a small number of players complained that some of the colors weren’t different enough, and it made the game a bit harder to play. To compensate in Chroma Circuit, I added a color-blind mode with very high-contrast colors. For Qrossfire, I tried to ensure from the start that the colors I chose would work well together aesthetically and technically. As a fallback, I also added unique shapes to go along with each of the colors.

Qrossfire In-Game

Qrossfire was the first game of mine to use the First Impressions feature on FlashGameLicense. It’s a wonderful option that puts your game in front of a variety of players with many backgrounds and skill levels, and you receive their honest feedback, as if the game were out in the real world. While I’ve heard that many developers put early versions of their games up there, I decided to upload Qrossfire later in development when I was mostly adding finishing touches. Regardless, the participants gave me excellent advice related to sound effects, difficulty, and controls. Between the comments from these helpful souls and very useful suggestions I received some of the potential licensees on FGL, I was able to make Qrossfire more dynamic, interesting, and universally enjoyable. If you sell licenses for your games on FGL, I highly recommend this feature, and I don’t doubt that I will use it again.

From the beginning, I intended to create Qrossfire using an established formula. While I strive to create unique games that stand out from the crowd and go in their own differing directions, even when we’re talking simple puzzle games, there are benefits to me as a game developer to building an old standard that’s tried and true.

• More experience. This is only my third game, and a good way to spend more time on graphics, sound, and other non-development areas is to create something that won’t require too much thought from the engineering side of my brain. This choice also lets me spend a bit more time refining the project structure and architecture. What I learn from those possible improvements, I can take with me to my next game and beyond.

• Creative exercise. What better way to force myself to be creative than to take an established—and nearly overdone—genre and try to find a fresh way to present it to players? A good balance between new and familiar elements is often the best way to find success.

• It’s relaxing. I have plans in the works for an epic sequel to Chroma Circuit with more levels, new game modes, and some very exciting new features—all of which offer me great revenue potential. I’ve also been experimenting and brainstorming for games in genres I haven’t tried yet. Giving my mind a short break from planning those longer-term tasks allows me to restart them later with a fresh perspective and new ideas.

Currently, I’m taking a short break from game development to do some Flex consulting work. I hope that games will be able to pay the bills sooner than later, but I’m still not there yet. Thankfully, I only need to work for about three months to allow myself to work fulltime on games well into 2010. Hopefully, I’ll get started on a new game in early October. In the meantime, I’ll be doing customizations for portals that want site-locked licenses of my existing games, exploring interesting technologies I may be able to use in my games in the future, and enjoying the summer as much as possible.