Archive for the ‘Sponsorship and Licensing’ tag

Selling non-exclusives

It has been the reason for many personal messages in forum and emails. It has been the “so sorry to bother you” private chat topic: non-exclusive licenses. Many developers want to sell it, others have portals interested in it, but have no idea of the price tag to put up or the money offered is acceptable.

Non-Exclusives 101

To accept non-exclusive licenses you cannot sell an exclusive one. So no sponsorship deals if you want license based deals going. You can have (and you should have) a primary license for maximum revenue.

Non-exclusive licenses must be site-locked to protect the primary licensee investment. The money you get for a primary license can be a good starting point for deciding prize tags for FGL Shop, but should not be used as a rule of thumb for every single deal.

Factors that influence the cost of a non-exclusive

Traffic… the hidden beast

A portal will buy the developer a non-exclusive license for several reasons but the first impact of having a non-exclusive site-locked game is that it won’t drive traffic to the portal’s competition that has the primary license. It’s not difficult to imagine that this means money.

In a way, a non-exclusive license makes the game exclusive to an already loyal portal user. This also explains why there’s a no link obligation in many requests for non-exclusive licenses. No links means no distractions. Traffic is the core product of most flash game portals and we must understand that.

Price wise, it’s pretty easy: the bigger the portal, the bigger the traffic, the bigger the need to make that traffic stick, therefor the higher the price and unlike what many developers say, portals are aware of that and are willing to put up a fair price.

Game Quality and Visibility

This should be pretty obvious. A better, deeper, more entertaining game will produce more hits to the portal that is licensing the game, therefor this should be reflected on the price. Sometimes this happens simply because the primary license offer reflects it.

This is even more obvious with well known IPs. If a game does well, players will recognize it later on and you’ll notice a snowball effect on some portals, made by players that have appreciated your work before.

Requests

APIs, logos, no links and so on. A lot can be asked for a non-exclusive license and these things take time. Not really a big issue, but you have to be prepared for it to make it worth.

Create your own custom buttons for your site for instance. These should have code that would read some “global” boolean if links are allowed or not. You can create your own API manager, preloader stuff and so on, anything that can make your code easy to adapt.

But there’s another side to it… each of these things add value to the portal and some even remove value from you. No links policy is a good example: traffic sticks to the portal and you don’t get a visit from your beloved players, thus not raising your own brand awareness.

So lowering your cost to answer these requests is by default best way to get a little something more from it.

How to calculate it?

Don’t… it’s my honest advice. Like I said above, the price of the primary can give you a basic idea to work with, but that needs to be adjusted to each portal’s size and requests.

On the other hand, or you have a known daily cost and daily goal and it’s matter of pure math to know if it’s a good deal for your or not, or you’ll be thinking time and time again if you are selling to low or not.

Don’t be radical

I guess the most difficult part of this is to learn to evaluate the game and the market porperly. On one hand, if you sell licenses to low, you’ll be damaging every developer’s business. On the other hand if you think too high of your game you’ll be damaging your own business.

While common sense says that you should bring the price as high as possible, sometimes it’s better to accept a low offer to increase your business in the long run or negotiate a high offer to position you, your brand or IPs or simply your business standing… just don’t be radical.

Vlad, logging out…

First Year of Flash Game Development: a Balance

I’m not aware of the exact date we said “We’re going flash games” but since I registered us on Flash Game License mid-July 2008 and our first game took about 6 weeks to be made, I would imagine that mid-June would be near the exact date.

I know it’s irrelevant, but I’m brainstorming so bear with me…

Technology was… refreshing!

Oh well, what to say… we used to work with Torque Game Builder and C++, mostly because Torque Game Builder had some… erm… issues. In those days, that damn thing didn’t know how to render a font on screen properly, so, to get a commercial game out, we couldn’t trust it and we needed to change the actual C++ engine.

Actionscript does have it’s issues also, first and foremost, it’s not a game engine, nor there’s any proper commitement from Adobe to change that. But game developers are used (and should be used) to make the wrong feel right and Actionscript is a bag of good suprises in that department.

Money was good!

Money is not only licensing… we did more stuff… but let’s start with the part that interests most developers.

Licensing

While I still believe that the topmost games of the casual download market space do make more money than topmost flash games. But download games take more time and more people. Another thing with the casual games is that it is a hit market and the vast majority of the money goes to a tiny minority of the people.

We released one download game and we were working on the second when we ran to an halt: we had a lot of proposals for distribution, none for publishing. If you don’t know what this means, basically we didn’t have any upfront money to work and that would kill us in a couple of months.

I would love to share with you real money values but under contract of the download game I cannot, therefor, I’ll give you comparasion figures. I calculated a revenue ratio:

revenue ratio = revenue / team members / months of development

Balloon Bliss has a revenue ratio of 1, because it’s what I want to compare with. Our first game, Tech Wars was a disappointment, mostly because we didn’t know what we were doing, but ok… still the revenue ratio is 1. This means that the revenue per month work per developer involved is exactly the same as a download game… hmmmm… for a game that is less market friendly.

Atomik Kaos and Atomik Kaos 2 have a ratio of 6 and 7.5 respectivelly and Lucy Swashbuckler has a ratio of 2.25.

Average is 4 times more revenue per team member per month worked than casual download market.

Contracts and Collaborations

We had some great ones and some bad ones, most of them were great ones though! Some of the contracts are yet to hit the web, which is a shame because we are very proud of them, but this section is about money so let’s cut the chase… is it good or not to have contracts and collaborations?

It depends… Using the exact same ratio, we had contracts that ranged from 1 to 10 and collabs that ranged from 0 to 36.72. The problem is that 0 there… some developers started projects with us, received assets and then dropped the project without a word. That’s nasty.

I think that we will have less collabs and more contracts in the future, which is ok I guess, but although a higher risk, it’s potentially more profitable to have a collab than a contract. Something we’ve discussed a lot is to what extent is more interesting to get these gigs instead of our own game development? On average our own game development is more profitable, but it has the highest risk, so I guess it’s a matter of balancing things.

Conclusions…

While we did more money per team member per month, we really need to sort how to balance between contracts, collabs and internal production.

Contracts offer 0 risk but lower income, internal production presents the higher risk with a potential higher income and collabs are somewhere in the middle. Since collabs were the more profitable the also the most problematic, I think that what we need to balance is internal vs contracts and leave collabs drop unless we get a really interesting project.

Visibility and contacts

Like it or not, a business is as viable as is it visible unless you are running some illegal thing, then it’s the exact opposite.

About a year ago our games were played by roughly ten thousand players. In a year we got around ten million players, that’s the equivalent to our country’s population, so kind of a milestone for us.

Our visibility, simply boosted and most of it happened because of the good people we had the pleasure to work with.

Flash Game License

All started here: please click here if you don’t know what it is… The services offered by the portal allowed all our primary and exclusive game sales, but it did not end there. Adam in particular has been always open to hear our complaints and suggestions and drive business our way. I’m sure we would do it sooner or later, but not has fast and as hassle free as while working with this wonderful group of people.

Portals

All the portals that worked with us. All, from the smallest to the biggest, have part in the visibility of our work but more important, all of them cared. I never felt that these portals were some faceless institutions that overloaded us with paperwork or false intentions. They wanted the best for their service and worked with us to deliver it. Sometimes it was possible, other times wasn’t.

I’ll open a new link section to be sure I don’t leave anyone out… and drive a little traffic their way too, why not?

Conclusion and future plans

This first year was very good. Next year is a bit edgy for us. We want to continue growing but we need to sort what our bets are and how we will manage somethings.

I don’t doubt for a minute that I’ll be here a year from now making a year 2 balance.

See you all soon,
Vlad

Site lock and domain name

If you are selling licenses of your games, site locking is something that you just have to know. One of the mistakes I did early on was to simply use some piece of code I found on the web. It was something like this:

What this does is to get the index (aka position) of the string “domain.com” from the string that is returned by the loaderInfo.url. If it returns -1 then the string “domain.com” is not present in the loaderInfo.url.

This solution is fine, but it presentes two problems.

First, if someone really wants to use your site-locked game, they can! They just have to find a way of putting the “domain.com” string somewhere in the path to your swf since this code does not compare the domain name but rather the presence of a string on another string.

The second problem is that you don’t know the domain where the game is present. I need that information for other evil schemes of mine, so this was the perfect reason to write a small tool that would fetch me the domain name.

So I wrote this simple static function that lies inside a class Toolkit -name I shamelessly stolen from a chat with Andrew from Epic Shadow- and that simply returns the root domain and the top level domain, separated by a dot from the loaderInfo.url.

The only issue I have with this function is that I have to pass the root as a parameter to the function. Any idea on how I could solve this otherwise is most welcome.

    Newer Entries »