|
 Features
The Pros and Cons of Licensing
 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.
|
|
|
|
|
Previous