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.

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.

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.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical"
	creationComplete="application_creationCompleteHandler(event)">

	<mx:Button label="Example" preinitialize="_exampleButton = Button(event.currentTarget)"/>

	<mx:Script><![CDATA[
		import mx.events.FlexEvent;
		import mx.controls.Button;

		[Bindable]
		private var _exampleButton:Button;

		private function application_creationCompleteHandler(event:FlexEvent):void
		{
			trace("_exampleButton:", this._exampleButton);
		}

	]]></mx:Script>
</mx:Application>

In the code above, there’s a private _exampleButton variable that will be used to reference the Button we create in the MXML without an id property. It is Bindable so that we can use its properties in binding elsewhere. Hooking onto the FlexEvent.PREINITIALIZE event, we pass the component reference to the variable using the currentTarget property of the event.

If you have a reason to enforce stronger encapsulation in MXML components, this method could be useful, but it’s probably overkill most of the time. Obviously, this won’t stop someone from using standard display list functions to access the child you “hid” by making it private. I doubt I’ll use this anywhere, but it was a fun exercise, and I thought I’d share.

A Couple Related Links

• Feature Request: SDK-219: Access-controlled MXML Properties

• Blog Post: Hiding Properties in Flex Components

To understand that better, you should first know a little more about how binding works. Normally, when you make a getter/setter pair bindable, the compiler adds a little extra code for you. Behind the scenes, it dispatches PropertyChangeEvent.PROPERTY_CHANGE to tell the binding system that your property has changed. Basically, it converts your property functions from something like this:

private var _example:String = "I am the very model of a modern Flex developer";

[Bindable]
public function get example():String
{
    return this._example;
}
public function set example(value:String):void
{
    this._example = value;
}

to this:

private var _example:String = "I am the very model of a modern Flex developer";

[Bindable("propertyChange")]
public function get example():String
{
    return this._example;
}
public function set example(value:String):void
{
    this._example = value;
    this.dispatchEvent(new PropertyChangeEvent(PropertyChangeEvent.PROPERTY_CHANGE);
}

If you don’t have a setter, there’s nowhere for the compiler to act smart and determine that your property has changed. If you want a getter without a setter to be bindable, you need to specify an event to be fired when the value returned by the getter changes. Your code should look something like this:

private var _example:String = "I am the very model of a modern Flex developer";

[Bindable("exampleChange")]
public function get example():String
{
    return this._example;
}

Notice the inclusion of the event type in the metadata’s parentheses.

That’s only the first part, though. Next, you need to actually dispatch the exampleChange event from somewhere in your code. For example, let’s say that we change the _example variable when an URLLoader returns a result:

private function urlLoader_completeHandler(event:Event):void
{
    var loader:URLLoader = URLLoader(event.currentTarget);
    loader.removeEventListener(Event.COMPLETE, completeHandler);
    this._example = loader.data.toString();
    this.dispatchEvent(new Event("exampleChange"));
}

Any time you change _example, you need to dispatch the exampleChange event specified in the metadata so that the the binding system knows about what you did. If you set _example in many different places, you might consider making a private or protected setter that sets _example and dispatches that event, but that’s not required.

In summary, the compiler warning goes away when you specify an event type in the metadata. Simply specifying an event type won’t update bindings though, you also have to dispatch that event when the underlying variable changes. When the binding system receives your event, it knows to update any component to which your getter is bound.

One extra thing worth mentioning is that any property with Bindable metadata that has no event specified with dispatch the same generic propertyChange event. This means the binding system will have to work harder than needed because it could receive the same event for many different properties. It’s a good idea to a create custom event for each property to avoid this limitation. You can see in the Flex framework source code that Adobe has separate events for most, if not all, bindable properties they create.

When you create an “fl” component that has children that are also “fl” components, you’re required to call a function named drawNow() on the sub-components inside the parent’s draw() function. You want to do this because many users will find it aesthetically undesirable to see those sub-components update one frame later rather than immediately. In fact, the architecture actually forces you to call drawNow() because it refuses to queue another redraw while in the “call later phase”. Of course, there are ways to force “fl” sub-components to invalidate during that call later phase if you don’t mind patching the source yourself, but that’s a different story.

Call later, or else!

That’s the background for how the architecture works. Here’s the problem I discovered. When you set a property of a sub-component from outside its parent, that sub-component will invalidate and callLater() will get it ready for a redraw. If, for some reason, the parent redraws before its sub-component, the sub-component will draw when drawNow() is called, but the redraw it independently queued up earlier won’t be removed from the queue!

The only time that the draw() function gets removed from the queue is when the callLaterDispatcher() receives the stage’s render event. Instead, UIComponent should account for the possibility that a certain functions that will be “called later” may not need to be called again if they get called early. Here’s a patch to fl.core.UIComponent that will do just that for component drawing:

protected function validate():void
{
	invalidHash = {};

	//remove draw() from the "call later" queue
	delete this.callLaterMethods[draw];
}

I simply added one line at the end of the function validate() This function gets called at the end of draw(). The default version only cleans the invalidation hash, which tracks changes to minimize the number of component parts that need to redraw. My addition also ensures that it only redraws once. If the component has validated, then there’s nothing invalid to require another draw.

It’s worth noting that an extra redraw isn’t the end of the world. For most components, it won’t cause any noticeable problems, but for some, it may impact performance. Things like the layout containers in Yahoo! Astra are a bit more CPU-intensive than most “fl” components because they need to determine ideal dimensions, the best positioning of components, and whether scrollbars are needed and that involves some nasty looping. They have a few flags to indicate whether certain changes affect the layout at all, but still, that’s not always perfect and drawing the component again for no good reason isn’t useful.

By the way, if you ever want to monkey patch a component in a specific Flash or Flex project, it’s easy.

1. Copy the original source file into a new file. Make sure the package structure is the same as the original.

2. Make any changes that are needed.

3. Add the folder for the top-level package of the new component to your compiler’s “source path”. Make sure your patched source is higher in the list than the original version so that the compiler knows that it is more important. Typically, if the patched version is in the project’s own directory, it will be given more importance.

Enjoy!