Archive for the ‘Sponsorship and Licensing’ tag

Sponsorship, licensing and publishing

Like I commented on Freelance Flash Games blog, I disagree with the current definition of sponsorship. I disagree not because I’m some kind of linguistics freak (English is not even my first language) but because I feel that the discussion of the terminology, together with experience and knowledge brought from outside flash game space can bring new ideas and new formulas to both developers and portals.

Sponsorship

Sponsorship is a deal where the sponsor entity gets itself associated with a sponsored entity in return for some commercial value that it would not have if there was no association. Translated to our reality: sponsorship is a deal where a portal gets associated with a game in return for traffic generated by that game.

In other sponsorable property it is possible to have several sponsors. Think about F1 cars or TV shows. As you may know, a sponsorship in flash games is exclusive.

Licensing

A license is a permission. Licenses are issued by city halls, governments, software publishers and so on. Every time you buy a game you are being granted a license, same applies to a movie. All content on each TV channel is licensed to be aired by that channel. When you drive a car, you have a license to drive and a license issued so that the car can use the pavement in your country.

Same applies to flash games. When a developer sells a non-exclusive site-locked license he is not being sponsored. He is granting the portal a permission to use his game. What about primary licenses… well… a primary license is somewhere between the sponsorship model and a true licensing model. What separates a 100% licensing model from what we have now is the primary licenses. On the other hand this licenses are what makes traffic go up and down, so until something special happens, I think it’s a good thing for everyone that it still exists.

One interesting aspect about licensing is that it is widely accepted that site-locking a non-exclusive license is done to protect the interests of the primary license holder. As I see it, it is protecting the interest of the developer because the non-exclusive site-locked license could exist and the viral version be used for commercial and brand awareness of the developer. If every single developer worked his own brand awareness by not selling a primary license, making the viral version his own and then selling only site-locked licenses we would have a full licensing model, which we can only speculate if it would work or not.

Publishing

From AAA console games to casual download games, there are a lot of games where a publisher finances the game. This is the foundation of the publishing model: a publisher accepts a project from a developer, funds it, markets it and distributes it. The commercial catch is that the publisher controls everything except the production. For all that matters, the property of the end product belongs to the publisher.

Apart from some portals internal development, there’s no real publishing space in the flash market. I don’t think that it is doable though. Publishing usually involves financing the whole project. I’m a firm believer that most sponsorship deals don’t cover the development expenses if most developers took their time to see the costs they had. So it is possible to get the same performance by sponsoring with an amount of money that isn’t quite the same as if the same portal was publishing the same game.

Hope this helps to sort some ideas out. Stay tuned on Freelance Flash Games blog… I know he has something to say about this too.

Signing out…
Vlad

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:

if(this.root.loaderInfo.url.indexOf("domain.com") != -1)
    trace("Good!"); // It's in the right domain
else
    trace("Bad!"); // It's in the wrong domain

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.

/*Returns the name of the domain without subdomain, e.g. vortixgames.com
 * instead of www.vortixgames.com.*/
public static function Domain(root:MovieClip):String
{
	/* Splits the full path into an array of strings separated by "/"
	 * and gets the index 2 value which is the full domain name.*/
	var currentDomain:String = root.loaderInfo.url.split("/")[2];
 
	/* Splits the result into an array of strings separated by "." and
	 * checks the length of the array. If the array has a length of 3
	 * the domain contains a subdomain, for instance "www" and it must
	 * be discarded. If the length is 2 then, there's no subdomain
	 * present. */
 
	var fqdn:Array = currentDomain.split("."); // FQDN in array form
 
	var rdi:int = 1; // Root Domain Index defaults to 1
	var tli:int = 2; // Top Level Index defaults to 2
 
	if (fqdn.length == 2)
	{
		rdi--;
		tli--;
	}
 
	return fqdn[rdi] + "." + fqdn[tli];
}

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 »