Addressing color blindness in game design

by Josh Tynjala

As a game developer, I try to be accommodating to all types of players. One thing I learned pretty quickly after I released my first web game, Chroma Circuit, is that choosing colors (especially in puzzle games) is very important and not a task to take lightly. Color blindness can easily make two colors that seem very different to me look almost indistinguishable to others. When gameplay only relies on being able to see the difference between colors, you’ve got a problem.

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.

Photoshop color blindness modes

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.

Spectrum as seen with Protanopia-type and Deuteranopia-type color blindness

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.

Screenshot of Chroma Circuit with color blindness mode enabled

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

Screenshot of Chroma Circuit mobile with Pattern Mode enabled

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.

Screenshot of Qrossfire's symbols

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.

Screenshot of Gridshock with patterns mode enabled

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.

Bioshock screenshots

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.

Screenshot of Puzzle Fighter with color blindness comparison

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.

Screen shot of Bejeweled showing the different shapes of colored jewels

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!

Image of playing cards

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.

Gridshock Mobile for iPhone (with Android on the way?)

by Josh Tynjala

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.

Gridshock iPhone title screen

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.

Gridshock iPhone game with patterns

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.

Chroma Circuit on Android!

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.

Adobe TV video about Packager for iPhone and Chroma Circuit

by Josh Tynjala

At the end of 2009, I released by my game Chroma Circuit for the iPhone. It was developed using early builds of the Packager for iPhone to be included with the upcoming Flash CS5. Adobe recently met with me to chat about my experience using this exciting new technology.

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.

Indie Flash Game Development: A 2009 Year-End Retrospective

by Josh Tynjala

In early 2009, I came up with an idea for a Flash game. At the time, I had enough saved up to take a short break from regular work, and I decided to try out game development on my own for a little while. That first idea eventually became Chroma Circuit, a cool little puzzler released by my new company, Bowler Hat Games. Since then, I’ve released two other free-to-play Flash games, one iPhone game using Adobe’s upcoming Packager for iPhone in Flash CS5, and I’m working on another iPhone game as I write this. The other day, I realized that I started creating games in January, right at the beginning of the year. With that in mind, I thought I’d take a look at how I did, financially speaking, in my first full year as an indie game developer. Get ready for some numbers!

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:

Time Spent on Projects. 33% RIA Contracts. 13% Game Contracts. 50% Bowler Hat Games. 4% Time Off.

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.

Income. 58% Game Contracts. 42% Bowler Hat Games. Time. 20% Game Contracts. 80% Bowler Hat Games.

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.

Bowler Hat Games Revenue. 54% Primary Sponsorships. 21% Non-Exclusive Licenses. 20% Advertising. 5% iPhone Sales.

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.

Pages: 1 2 3 4 5 6 7 8 ...46 47 Next