The Not-So-Golden Archbob

A thread erupted on the FlashGameLicense community boards surrounding this post by free-to-play Flash game portal owner Yinan Chen, AKA “Archbob”, who runs FlashGameNinjaClan (which we “featured” in our recent post Why Don’t You Host Your Own Flash Game Portal?):

Mochi Leaderboards and Mochi Coins

Understandably, members of the developer community took exception to a few things Archbob had to say:

I don’t care how much the developers earn. The ones that make good games can easily make several thousand or tens of thousands per game.

and this gem from another unnamed portal owner:

I am sure Flash Game Developers make a lot of money already. [Microtransactions are] kind of greedy.

Hulk … rage … building. Sigh. Don’t get me started.

In the article, Archbob does voice some valid concerns about the implementation of MochiCoins and competing services from his industry perspective. He also goes on to shock some Flash game devs by detailing his practice of paying developers $100-200 for full source code to a game. This has led to a number of threads and posts on the subject of selling source, not least of all this post from the Vortix Games Blog:

Thinking about selling your source code?

Your Question, Answered

At the end of the day, Archbob is just a bidnessman looking to make a buck and doing it the most efficient way possible. If some devs are willing to part with their code for a pat on the back and some lunch money, it’s on them, not on Archbob.

But now that we’re all here, Flash game devs, let’s talk about this whole source code issue. What’s the deal, anyway? Should i sell my source code?

The short answer to that question is “no.”

The long answer is “no.”

The answer, translated into French, is non which, loosely translated back to English, means “no.”

The answer in the African click language Mbukushu is “nglOCK”, which – you guessed it – means “no”.

So a new question arises: have we, Untold Entertainment, ever sold our source? The answer there is actually “yes”, but to understand why, i have to take you back to a simpler time.

Let’s Do the Time Warp Again

Picture it: the year is 2007. George W. Bush is in the White House. “Fergalicious” by pop chanteuse Fergie (featuring will.i.am) tops the Billboard Hot 100, a popular music chart of the day. And the star of the Flash game development scene is a high-level programming language called ActionScript 2.

“AS2″, as it was known in jive-talking developer circles, was not a full Object-Oriented programming language. You could, with a little facial straining and a lot of undocumented wizardry, shoehorn it more towards an OOP mould, but most of us with a day job and one-week-long game production deadlines couldn’t be arsed. Those days, creating a new game meant coding it largely from scratch, or keeping a folder full of code snippets to copy-paste into a new file. Reusable code was a tale told by futurists and mad-men. Chaos and disorder ruled the day.

When our clients would request our AS2 source code for a week-long game like Eye in the Sky: Spot the Differences, it was hard to kick up a fuss. Many of our clients are kids’ television production companies who convince themselves that they’ll have the time and money to repurpose these games later, but nothing ever comes of it. If a different client were to come to us and ask for a nearly identical spot-the-differences game, i’d probably code it from scratch. The new client’s concept would probably be just subtly different enough to warrant a re-write.

But then along came a stranger to the scene, a wild-eyed and vivacious newcomer with a mane of saffron-coloured hair and a tight pair of rhinestone-studded spandex pants. “Actionscript 3″ was his name, and the industry would be changed forever.

The difference between AS2 and AS3 is that Actionscript 3 has really lived up to its promise of code reuse. Problems that used to take us days or weeks are reduced to literally a single hour, leaving us to catch up on our knitting in those long, tranquil stretches of Wednesday afternoons. AS3 has also changed the way we negotiate our contracts with clients.

AS3′s Impact on Contract Negotiations

The clients will always ask for source code, and we will always say no, for these very valid reasons:

1. By selling your source code, you are selling the right to use that code. You can’t (contractually) sell your code to someone and then turn around and re-use it in a new game.
2. With each new project, we re-use and improve upon libraries that we used in past projects. If we sold the code in those libraries, we couldn’t (contractually) use them in our next project, so our profit margins would shrink because we’d have to [technically] re-write the code.
3. The time and effort we put into some of our libraries is very valuable to us, and can represent literally years of development. We’re not going to let that fly out the door for the cost of a few weeks’ development.

To use an industrial analogy, selling your source code isn’t like selling a car. It’s not even like selling the plans or the autoCAD blueprints for the car. It’s like selling a machine which, when you push a button, makes a car.

So no, clients cannot have our source code. But this presents us with a problem: what happens when the client’s database guy needs to integrate the game into the high scores system, but he’s only available in November, and we’re finished with the game in October? Or what happens when the game is a component of a much larger website, and the client requires source code to integrate the game? Or what happens when the style bible changes and the client wants to make a character’s hat blue?

These are all real-world examples from our actual experiences. You hard-lined developers might say “if they want the hat blue, they can pay us to make that change.” But our policy has always been to enable the client to make reasonable changes after the fact, without having to pay an expensive Flash developer for simple modifications. That’s why we try to link copy decks in xml files outside the project. The client shouldn’t have to pay us more money because they want the Registered Trademark symbol added to a product name. (And, honestly, we don’t really want to halt production on a new project to make such a small change to an older project anyway).

We’re currently building a music game. What if the client finds out down the road that the rights to the songs have changed? Should they have to pay us to put different songs in the games? In my opinion, no. So we’re building the game so that it’s easy to change the playlist externally.

And the hard-line approach does nothing to solve the problem of site integration. Clients simply need source code in that case.

So what is the solution?

Enter the Shared Source Agreement

Since we started developing games in Actionscript 3, we’ve signed a Shared Source Agreement on nearly all of our projects. That’s where we can:

• Re-use
• Re-configure
• Re-sell
• Re-skin

the source code, and our clients cannot. But we do give our clients the source code, with a license to modify that code within the current skin. That means that if we’re making a game about bears who love the delicious crunchy taste of Goorman’s Cookies, the client can’t turn around use the source code to create a game about a bee who can’t get enough of the satisfying crackle of BingBong’s Peanut Brittle. They can do whatever they want with it, as long as they stick to that bear with those cookies.

The Honour System

“But if you give the client your code, aren’t they just on the honour system?” you ask. Sure they are. The client could turn around and do a variety of things with the code that weren’t contractually permitted. But as human beings, we rely on the honour system a great deal. The honour system is what keeps you from walking down the sidewalk and stabbing someone in the face. It’s what dissuades you from veering your car over the yellow line on the road and into oncoming traffic. i like the honour system. Let’s stick with it.

If it helps you with your own contracts, or if you’re one of our competitors looking to get an edge on us, here’s the kind of wording we use when we work with a client on a fee-for-service basis:

The source code for this project is licensed to [Client] under a Shared Source agreement. Untold Entertainment Inc. retains the exclusive right to modify, reuse, re-skin and sublicense the source code, and any non-brand-identifying multimedia assets. [Client] may modify the source code solely for the purposes of [project]. Untold Entertainment retains the know-how and materials to this project.

Know-How! (Contrariwise!)

When i first saw a client try to retain “know-how”, i actually had it stricken from the contract. How could someone else own my knowledge of how i did something? Did i have to erase my memory or try to blot knowledge from my mind? (Of course not. Apparently, i’m pretty good at naturally forgetting how to do things.)

i came to understand that retaining “know-how and materials” is strictly legal language pertaining to a research grant (SR&ED) here in Canada. He who writes that language into the contract gets to apply for the grant.

Let Us Retire to the Sitting Room

So this post is meant to help you out if you’re looking to do some fee-for-service work (we geev you the Flash, you geev us the monay) and you need this kind of help with your contract. i hope this post doesn’t serve as bait for an army of hobbyists telling me how great it is to sell your source code. As always, i welcome lively discussion either here or on the boards. And if this post has taught you nothing and you’re still interested in selling your source code to me for a few hundred bucks, please drop me a line. :)

Ryan Henson Creighton is a Toronto-based game developer, and founder of Untold Entertainment Inc., specializing in online games for kids, teens, tweens and preschoolers.

Ryan Henson Creighton

View all posts by Ryan Henson Creighton

Popularity: 3% [?]