Sponsored By

The Pros and Cons of Licensing

AWE Games' Scott Nixon (_SpongeBob Squarepants, Cars, Agatha Christie _franchises) discusses best practices for developing a licensed video game, from inception to resource acquisition and beyond.

Scott Nixon, Blogger

December 6, 2006

15 Min Read

For a small developer, the opportunity to create a game based on a licensed title is a decidedly mixed blessing. Publishers often view the process as assembly line game making of the basest sort, eschewing innovation for pandering to the lowest common denominator - and doing so with cut-rate budgets and shockingly short development cycles. To add insult to injury, it is not an area that garners much respect from fellow developers, and you can expect at least mild ostracism at trade shows. In many ways, you are doomed before you even begin.

It isn’t all bad, and there is an upside of sorts. You are granted a built-in user base, a wealth of source material, and - usually - relatively strong characters, storylines, and voice actors to work with. Notwithstanding, it is a tricky - often thankless - endeavor, and hopefully some of this information will serve to inform small developers what they can expect when tilting at the big bad licensing machine.

Slow Assets

Theoretically, when it comes to asset build-out, licensed titles should have a marked advantage when measured against their unlicensed counterparts. In most cases there exists a treasure trove of source material that could make your job much easier – if you could only get your hands on it. In stark contrast to their enormous popularity and the fact that they cater largely to the golden demographic of commerce, most license holders don’t treat games as the priority their profit potential warrants. With luck, you have a publisher that really pushes the issue and gets you the resources you need in a timely manner.


AWE Games' Agatha Christie: Murder on the Orient Express

Sadly, rushed development cycles and legal issues make this a perpetual issue, and the best you can hope for is minimal delay. It isn’t a matter of wanting to take shortcuts by using someone else’s work, it’s a matter of getting reliable and concrete proof that location A looks like location A and that character A does indeed have four spots just beneath his left ear. Guesswork is almost always wasted time, and, in the absence of assets, getting answers on the simplest queries about color or composition may be near impossible.

Get used to hearing the phrase “I’ll get back to you by Wednesday on that” – especially on Thursdays. In the end, licensed assets are a dubious boon; any advantage you hope to gain by using them is usually negated by their lack of timeliness and the fact that you need to match them so closely.

Broken Telephone

For any given license there is a large amount of variability in the details, and these details can make a developer’s life unbearably difficult. Most troublesome are the often convoluted relationships between the publisher and the license holder. Even if the publisher’s contract explicitly states that they have final approval on all assets, most will be reluctant to override any issues brought up by the license holder. This is understandable; it would be foolish for a publisher to rock the boat, especially if the license is proven in the field. Unfortunately, the upshot is that this onus gets passed on to the developer - who has just unwittingly taken on an additional set of opinions to deal with and opened themselves up to be liable for any miscommunication between licensor and publisher, as well as publisher and developer. This is further complicated by the fact that you are often dealing with more than two parties.

AWE has worked on projects with no less than five chefs (the creators of the license may not be the owners of the license, or may have been bought out by a parent company, but in either case you are dealing with two distinct entities.) Emails can take days just getting through the chain to reach their intended target. The lines of communication are mangled and the messages are frequently irrational or uninformed. There is no accounting for a license holder’s expertise in the gaming field and, with a few notable exceptions, most have none.

It can be very frustrating dealing with opinions by committee, or with people who have never played a game before and don’t understand what is or is not feasible – to say nothing of what is or is not fun! Publishers will often bridge the gap with understanding but, as often as not, without budging: “It’s a silly idea… but they really have their hearts set on it, I think we should just go ahead…” This is something that any small developer should be wary of, lest they run their personnel and finances into the ground courtesy of a single glib remark.

Get all abstract design ideas thrown at you as whittled down as possible before implementation, and be sure you have them all in writing. These things won’t make much difference if the powers that be have a change of heart two weeks before alpha, but at least you won’t look like you weren’t listening, or that you executed their idea poorly.

Freedom to Fail

There are few things more disappointing than working for nine months on a license that you’ve never heard of, only to have that property sink like a stone shortly after you publish - dragging your hard work down with it. This is a commonplace occurrence, but I’d happily argue the other side and suggest that there is reason to revel in obscurity, because if a title becomes wildly popular you will likely find yourself dreaming of the old days when you had the freedom to be daring.

When AWE Games started working on the first SpongeBob SquarePants game, no one in the office had ever heard of the license. We were sent and watched every existing episode, and although we found them quite funny, I don’t think any of us thought the show would be successful. Because of the status of the license at the time, we were given free reign with it, and as a result, the development process went quite smoothly.


2001's SpongeBob Squarepants: Operation Krabby Patty

After the initial title was published we immediately started developing the second. That game was the most personally gratifying, because SpongeBob was just beginning to get popular, but the clamp from publishing had yet to come down on us. From the end of that title onward (we went on to make four more), an increasing amount of time was spent agonizing over model specifications and location approval and much less time on game design.

So keep in mind there are worse things than obscurity. Namely, bureaucracy.

The Publishing Connection

The link between a publisher and an independent developer has always been tenuous, but nowhere is that link more vulnerable than with a developer that deals in licensed titles. They are seen as pedestrian and easily replaceable, and while I wouldn’t exculpate the developers completely, much of this view stems from the nature of the projects themselves.

Licensed titles are low-risk ventures that publishers use to offset high-risk original IP. For a publisher, these titles are money in the bank, and innovation is often seen as a liability. The budgets - and more importantly, the schedules - allow for little to no preproduction time, and this usually means the developer falls back on what they know best.

This makes for a serviceable workhorse of an end product, but it is chiefly responsible for the middling reviews and general scorn heaped upon most licensed games, and it hardly makes a developer invaluable to anyone. It breeds the attitude that the publisher is doing you a favor by allowing you to work on such a well-known brand, and that you should be grateful for the opportunity. This is not conducive to morale and can easily become a vicious cycle.

The Developer’s Toolkit

What can a small developer do to minimize man-hours lost in the labyrinthine process of working on a license?

There are many tools that can offset at least a fraction of the time and effort lost in the melee. Take them all with a grain of salt.

  • Throw your producer a bone. Producers on the publishing side of any project have to eat. It makes no difference if you are a developer with plenty of licensed titles under your belt or one with little experience in the field, you will likely be treated as an errant child either way. If developers consistently handed in publishable content with no need for revision or guidance, producers would be out of work. Luckily for them, this rarely happens, and it’s good to have an objective opinion about your project.

  • Remember, this person is your link to the publisher, and developing a good relationship with them is almost as important as turning in excellent work. Producers are rarely cheerleaders, and for the most part, the less they say, the better you are doing. Expect criticism, requests for wholly unnecessary and subjective changes, and the occasional thinly-veiled insult. Take them in stride and fix what you can - whether you agree with it or not.

    The important thing to do is keep the balance sheet running in your favor, and when the inevitable crippling issue comes up - the previously mentioned glib remark that would add weeks to your development time and lots of red ink to your balance sheet - cash in and get your producer to go to bat for you.

    It would be remiss of me not to mention that this technique fails about as often as it succeeds… use with caution.


AWE Games' Cars: Radiator Springs Adventure

  • Submit incomplete work. Of all the issues mentioned, this is the touchiest. How could it be in a developer’s best interest to not submit the best work they possibly can? The reasoning is a corollary of point one, i.e., a producer has to eat.

    Give them something to point out, something to fix, something to lecture you on – this makes them happy! When you get your milestone comments back, you will already have half or more of the critiques in the bag, and the producer will be ecstatic when you turn around the next one and everything mentioned was fixed with nary a complaint.

    This rule doesn’t always apply; you should feel out your producer first, many of them are secure enough that they won’t ask for changes just because they feel the need to justify their job.

  • Always integrate at least part of the feedback on any given subject. If you get a page of comments back on a model, quickly go through the list and separate out what is a minor tweak and what is a major overhaul (often what a producer thinks is a minor tweak turns out to be a major overhaul, and if they are made aware of this fact they may recant.) Address all issues you can, even if you may not wholly agree with the criticism.

    Again, the goal here is to keep the balance books tipped in your favor so that, if catastrophe strikes, your reserve of goodwill (hopefully) offsets the scale of your blunder.

  • Keep excellent records. This should go without saying. One of the biggest problems of multi-tiered development is communication, and the blame lies equally on all parties’ shoulders. Save all your email correspondence, and should you be connected to your producer via instant messenger, log all conversations.

    Try to avoid making big decisions by telephone. If that isn’t feasible, ask your producer to send you an email at the end of the conversation listing all salient points. Bear in mind that this can work against you just as much as for you, but at least you’ll be able to settle disputes and figure out who obfuscated what.

Try to figure out what your problem areas are and schedule around them. I know this seems about as useful as saying ‘just find out the problem and fix it,’ but if you are working on a sequel, or working with a publisher/licensor you have a history with, you may have a good idea going in what gets hyper-scrutinized and what gets the blind eye.

Frontload you schedules accordingly, but do it internally, not externally. The publisher doesn’t need to be privy to the fact that you don’t need the character orthos until next month. It’s safe to assume they aren’t in the business of keeping you in the know, so apply the pressure (you know you won’t get what you ask for on time in any case).

  • Get a prototype up and running as soon as possible and test out all your written dialogue. This also seems like a no-brainer, but when you have voice talent running quadruple union scale, paying for and scheduling a pick-up session is like pulling teeth. It also seems to be the industry standard that, no matter what your development cycle, VO is always recorded two months too early.

  • Test out your dialogue trees (if you have them) and try and ferret out where you are going to need incidental VO. You never know when you might get a call from your producer saying that the A, B, or C-list actor you are using is no longer available in July, so the VO must be recorded in May. It also isn’t a bad idea to keep a running list of useful phrases that you can update and use across many games - simply tweak it based on character/gameplay and submit that along with your regular VO to try and cover any oversights.


SpongeBob Squarepants: Lights, Camera, Pants!

  • Do not count on any existing assets to reduce your development time. It’s all too easy to be sweet talked into cutting months off your schedule with promises of pre-existing character models, music, backgrounds, reference, etc. Don’t buy into it. Usually the music will end up not getting clearance, and the backgrounds and other reference will arrive just in time for beta. Assume and schedule for complete build out, and use any time gained by using pre-existing assets to take a weekend off once in a while.

  • Finally – and most importantly – become an expert in the property you are working in. Scrutinize your own choices and make sure you are comfortable that they are to brand, or have precedent - even if your producer doesn’t seem to care.

    There is good cause for this concern. Producer turnover rate is notoriously high, and more likely than not you will eventually find yourself given a new producer halfway into a development cycle. This new producer will probably want to assert him/herself, and the easiest way to do that is by challenging decisions made by the outgoing producer (or by you) months ago. If you are versed enough in the title to be able to justify and defend these decisions, it will save you mountains of redundant work.

The Game’s the Thing

Treating a license gingerly is a sure way to make a mediocre game, and this attitude is all too prevalent, especially if the license has clout. Most publishers don’t care about the bad reviews their titles get in print and online, because the people they’re targeting don’t read reviews. They are aiming at those they see as the uninformed – either people who don’t play games enough to read up on them or young children.

This seems like short-sighted reasoning to me. Licensed titles often serve as gateway games for people who have never gamed before. This should matter to the entire industry - if your first gaming experience is a bad one, you may very well be turned off to the enterprise for life. I think most people would rather play a game that fails miserably at trying to be original, or at least well-crafted, than one that succeeds brilliantly at being pedestrian or ill-contrived. Astoundingly, conventional wisdom does not support this view – at least for licensed titles.

The fact is you don’t need to play games every day to be able to tell an exemplary game from an unremarkable one. As an industry, we should give more credit to the casual gamer than that. So when you get the call asking you to develop a game based on the next big thing, try not to get stars in your eyes. Don’t let the title dictate the gameplay, don’t pander, and, most importantly, don’t be suckered into a six month development cycle… hold out for seven.

Read more about:

Features

About the Author(s)

Scott Nixon

Blogger

Scott Nixon is Project Director at AWE Games. He has worked in the fields of management, art, and design on projects including Agatha Christie’s Murder on the Orient Express, Cars, SpongeBob SquarePants, and the Civilization series.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like