Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Freelancing Without Being Freely-Lanced
by Will Hendrickson on 02/26/14 09:59:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

The Basics

So, you have the skills, a portfolio/CV/some published work, and you need to make some cash. Clearly, freelancing is a great option. It allows you to generate revenue doing something you enjoy, make new business connections, and often even make your own schedule.

But, there are pitfalls and hidden issues, and the possibly difficult task of self-management. On top of that, each client seems to want to pay you differently: some want an hourly quote, some want to just pay for the whole thing all at once, and often times something in-between.

Then, there's the problem of scope. If you are freelancing as an individual or small company, the actual scope of a project can be difficult or sometimes actually impossible to determine.

Finally, to be successful, you need to generate a basis of consistent contracts coming in and being completed. Everyone needs job security, and freelancing is no different.

Trusting the Client

First of all, just don't. I mean this in a tentative sense, because by taking a contract, a certain level of trust must be assumed. But, since freelancing quite often involves working with largely unknown companies or individuals via the internet, you will often find yourself in a situation where there is little accountability, or recourse if things go wrong. Of course if they do go wrong, there is sometimes the possibility of litigation, so you need to be very careful how you deal with perfect strangers offering money.

As much as I wish it weren't true, there are a lot of unsavory characters out there. Some of them are trying to get something for free and can easily take the obvious route of just not paying for your time. But, often times the threat is more insidious than that.

Take the following example: You are a freelance programmer, and a client asks you to develop a first-person shooter. You spend a lot of time and effort iterating on the systems, perhaps using some of your existing code base. At the end of the project, the client has paid you in full and you've delivered as expected. Sounds great, right?

Wrong! Now, the code that you produced for the client, including your existing code base, are their "intellectual property" and they are voracious about protecting that exclusivity. Later, they send you a letter stating that they know you used 'their' code in a project for another client, or your own game. Believe it or not, some clients will try to keep tabs on you so that they can pounce when you become vulnerable. They might be looking for easy profits, cheap work, or they might just be trolls.

This can be very difficult or even impossible to defend against, in no small part because of the often exorbitant legal fees associated with litigation defense. While this rarely happens, it is possible, and you need to be very clear about who owns what when you're negotiating contracts with new clients. In some cases, patterns can be matched by decompilation of source code, so some unsavory characters might use this to try to coerce you into bad contracts, or attempt to destroy your ability to function as a business.

This same principle applies to base models, texture assets, sound samples, or really anything that a client could request that you produce, or even parts of what you produce. Be very careful.

It is important that you state very clearly at what point, if any, they gain ownership of the source code, and what level of ownership they have. For example, you might allow them to own the specific version you have sold them, but not the underlying code base or certain parts of the code. Personally, I never sell the intellectual property rights to my program code. Instead, I sell the client a non-exclusive license to use that code until the end of time, for commercial purposes, but not to redistribute the source outside of their company (binary form only).

Sometimes, clients have clients of their own, in which case this does not work. You can't please everyone; just make sure that you are pleased, and understand the legal risks associated with freelancing; it is a business endeavor.

My policy is very strict, because I have little stomach for legal risk, but this also partially excludes me from the marketplace: many clients are screened out because of this licensing policy (about half). You might want to modify this a bit to be more lenient, in which case you need to seek the advice of a lawyer who is vetted in game industry intellectual property litigation.

I find this is a blessing. A client might complain about "what keeps you from copying my game?" but this is a cop-out. In many cases, the client is simply trying to control you in the darkest sense of that word (see the link on 'trolls' above), because the program code itself is not what makes the game what it is. Be wary of these types of clients.

Work Formats

No matter what your primary discipline is (even if you have no primary!), there are always going to be essentially three types of work formats you will encounter:

  1. Hourly pay
  2. "Chunk" or per-project
  3. Commission

First, hourly pay is the most ideal as far as income potential, and mitigating the risk of nonpayment. The problem is, almost every client that wants to pay this way will want full 100% ownership of the intellectual property rights to the content you create. In some cases, such as original art, this is OK, but be very careful when accepting this work for programming jobs. Program code has a very dicey reputation in courts when it comes to IP, being considered both patentable machinery, and a literary work (like Moby Dick) to many courts.

If you are going to work on a remote but hourly basis, I recommend oDesk to both clients and developers. It tracks hourly work quite well, by taking screenshots and monitoring usage, and helps make sure the contractor is paid for the actual hours worked. That way, if things go south with a client, they don't have the option of total non-payment, because oDesk pays the contractor automatically. As a client, you have some assurance that the billed hours are actually consumed by work, because of the screens and monitoring functionality.

What I like to call "Chunk" is my favorite, as long as the project can be split into appropriate chunks and each chunk completed within a reasonable time frame. This is because clients wanting work completed in chunks are often willing to negotiate the contract terms more freely than hourly clients, and generally have a whole bunch of chunks that they can keep sending your way. This is a great format for acquiring repeat business.

Finally, there is the Commission-based contract. While the allure of infinite riches may seem irresistible at first, with clients pitching fail-proof games that you just know will become the next Minecraft, the reality is that most games are not that successful and you can easily lose a lot of money on these. And, in the rare case that the game is successful, some clients may attempt to duck out of the agreement somehow, potentially even by hiding financial information, or legal trickery. Avoid these like the plague! Commission should only be considered if you know the client personally. And even then, I still don't recommend it. There is just too much that can go wrong.

Scope

Determining the scope of a project is absolutely vital to your decision about whether or not to take or leave a contract, and how much to charge. But, it can be one of the most challenging aspects as well.

First of all, you need to have a wide basis of existing experience. Don't just work on projects of one size or type, but vary them within your comfort zone (and a little outside of it). The more experience you have with variation, the easier it is to evaluate any particular contract.

For "chunk" work, this is especially vital. Use your best judgment and compile your experience on the contract in question. Then, sleep on it. If, after careful consideration, you are still unsure, be transparent with the client: tell them it will cost at least X but might be as much as Y and that you will do your best to keep cost down. If they don't like the price you need, don't be afraid to walk away. There are thousands of clients seeking game developers of all stripes right now, so the ball is in your court, so-to-speak.

Repeat Business

This is where all of your fantastic negotiation skills come into play. If you deliver consistently high-quality work, on-time, and maintain a positive relationship with a client, it is entirely possible (and indeed likely) for them to return again and again. You can't please every client (because honestly, you don't want to) but by keeping the good ones close, you can ensure that all-important job security that is so scarce in the game development industry these days.

Often, after completing work, you might not hear back from a client. In fact, if you stay passive, you often will not hear from them again at all. They haven't stopped working, they have just forgotten about you.

Don't let them forget! Be polite, space your messages out, and just drop a friendly "how's it going?" every once in a while. You will often just get some small talk, but you will also get your fair share of repeat business this way. Don't wait for previous clients to remember your awesome work; they work with tons of people all the time who make awesome work! Be the contractor they want to work with instead. Be more friendly, transparent, and professional than the others, because otherwise you will just be drowned in all of the noise.

In my time as an independent developer, I've worked with a ton of different clients. They have kept me afloat, granted valuable experience, and even in some cases have become friends. While there is a certain "yuck" factor for any indie who finds themselves looking towards freelancing, once you get into it, freelancing can actually become quite rewarding and might even be the difference between the success or failure of your dream project.

Stay frosty!

Disclaimer: I am not a lawyer, and this blog post does not constitute legal advice. Always speak with a lawyer before entering into any contract or starting a new business venture. This advice comes from my own experience, and yours may differ significantly. You are warned.


Related Jobs

Red 5 Studios
Red 5 Studios — Orange County, California, United States
[10.24.14]

Graphics Programmer
Red 5 Studios
Red 5 Studios — Orange County, California, United States
[10.24.14]

Gameplay Programmer
Gearbox Software
Gearbox Software — Plano, Texas, United States
[10.24.14]

Server Programmer
Giant Sparrow
Giant Sparrow — Playa Vista, California, United States
[10.24.14]

Junior 3D Artist






Comments


Kain Shin
profile image
Great advice. Especially about code IP rights.

Jonathan Jennings
profile image
Hi Will I was wondering if you had any advice on whether or not it's ok to ask a client to see the state of a project before agreeing to work with them ? I had an experience last year where I talked with a client who had nothing but bad things to say about his previous programmer but really understated how much work was left to be done on the project .

we had a simple agreement where I would get paid once milestones were completed and could leave at anytime but once I pulled down the project I saw it was nowhere near as complete as I was lead to believe and in order to complete the milestones I would have to basically do a lot of house keeping before I could really even complete the tasks assigned to me .

In the future I would love to avoid this situation but I feel like asking to see the state of a project could come off badly , do you have any advice on the best way to approach a situation such as this when freelancing ?


none
 
Comment: