Sunday, March 1, 2015

The case for an Unreal Engine royalty cap

Unreal Engine 4 is fantastic. It's a great bargain compared to the old days where you simply could not buy this kind of power at any price; by this I mean the engine capabilities have evolved substantially in just a few short years. A lot of this stuff just didn't exist, but it does now and it is available at a price almost anyone or a small group serious about making games can afford. For less than $20 USD per month you can develop on one of the finest tools of its kind. Of course, there's a catch, and it's one that I have been finding difficult to come to terms with. When the subject comes up with my game-industry peers I find it's an even bigger issue for most of them than I expected. What I'm talking about is of course the 5% royalty on gross income from most of the profit of a successful game made with Unreal Engine 4 (this is a generalization, please refer to their license for specifics).

As I understand it, a developer will pay 5% on any gross proceeds made beyond $3000 per quarter, without limit. Personally, I'm not sweating this too much because when I do the math it turns out anything I do will have to make quite a few sales before it would have been cheaper to use Unity.

Let's use the Unity subscription rates for comparison, because they are essentially the same as buying a new license every two years. I don't know the history of Unity's upgrade fees, but since I'm talking about lowest immediate cost of entry here the subscription makes more sense to compare. If you combine the significant platforms and their costs ($75 Unity Pro, $75 iOS, $75 Android), it turns out to be $225 per month in Unity fees, or $2700 per year. That's it, nothing more to pay. You can even dial costs down a bit until you actually need the platforms too, but putting off platform testing introduces significant risks I usually advise against.

On the other hand, Unreal is about $240 per year, plus 5% of gross above $3000 per quarter. The amount you'd have to make with an Unreal game before the royalties started changing the cost to more than $2700 is ($2700/5 * 100 + 4 * $3000 - 12 * $20 =) $65,760. It seems we can conclude that if you expect your game to make less than this amount then it will save you money to use Unreal. That's great! I like saving money. Except, who really wants to aim for such a low number of sales? There is of course the option of buying a full license to Unreal, but if rumors are anything to go by this is an option only the largest of studios can realistically consider - we are talking about orders of magnitudes more cost than Unity itself. As far as I know, Epic doesn't share these prices and I'd guess these would be negotiated deals with other factors involved.

If this all makes sense so far, then you might agree that Unreal is utterly fantastic deal for hobbyists and indies with no expectation of getting a big hit. If, like most indies, you have in the back of your mind the idea that your game might actually become popular, it follows that perhaps it makes more sense to go with a platform that doesn't have potential to cost 2, 3, 10 or even more times than another popular and well supported platform.

It could be argued that the numbers start making sense when you consider most games are made by teams. Consider a moderately sized team of perhaps 10 programmers with a mix of two licenses (say, pro + ios or android) at $1800 * 10, and 10 artists/designers with only the editor ($900 * 10)  this comes up to a yearly Unity cost of $27000. The team would have to sell $551,760 to start saving money over Unreal's royalties. This may sound like a lot but with 20 people on staff I'd hope this is well below the project goals.

Where it gets biz-dev people nervous is when they start considering numbers in the realm of a game that might actually pay for a team of this size. Lets say for instance it takes 20 people at 50K each total cost to make the game. That's a million dollars. You have to earn a lot more than that to get the game out the door and lets say it actually takes closer to 2 million by the time its done. Finally, the game is in the market and sells just barely enough to pay that off. 5% of 2 million (disregarding the 3k per quarter allowance) is $100,000. You could get Unity subscriptions for everyone on the team, hire another developer, and still be tens of thousands of dollars ahead. And the numbers get even better if the game sells well or if the payroll costs are more realistic than the low numbers I gave.

If for the moment we consider Unity and Unreal roughly similar in their ability to serve as a functional cross-platform solution for a team to deliver a game with (as perhaps a biz-dev guy might be thinking), it would seem that one of the only situations that makes sense to use Unreal is if a few thousand dollars per developer per year is enough to put the business at risk. That would be a pretty tenuous situation, to say the least, and is the core of the argument my industry peers have had against choosing Unreal.

Having used Unity daily in my work for some time now, and Unreal only in my limited free time during this past year, I think there are a lot of good things to say about both engines. I'm intrigued by that Unreal has to offer, and I'm personally interested in learning more about it. It does a lot of things very well, and I enjoy using it. Unfortunately, it seems pretty clear that if Epic doesn't change their fee structure they will never be able to counter that hard argument that most games can be made with the small, budget-friendly and well-defined limited costs of Unity.

This is fixable.

Epic could put a cap on the royalties. Something more than the total cost of Unity, but less than "unlimited". There is a sweet spot somewhere which would make sense for people interested in the unique features Unreal has to offer. A limit that would be palatable to small and mid size groups or studios.

While you could juggle numbers and come up with a figure that sounds good (I like $50k, for instance), I think perhaps a better solution may be to cap it on a per-user basis subject to the audit requirements similar to what is already required for the quarterly payments. Perhaps $5,000 per title per developer, something along those lines. On the other hand, a simple royalty cap on the title itself is easy to communicate and can be dialed to a more acceptable number than "5% of everything".

I should point out the presumably obvious - Unreal is not the same as Unity. You can do different things with each of them. One may be more suited to a specific task that makes this whole discussion not as important as which is best suited for the job. These tools are often lumped together, as I did in most of this post, but the truth is they provide fundamentally different experiences and results. As a programmer I understand this, but from a business perspective the distinction is not always so clear.

On a related note, if you're a tinkering hobbyist and don't really care about the business end-game it's pretty easy to pay $20 a month and just have fun. If you get a hit, great, and the cost of entry is well within the "bring a sack lunch twice a month" range for most people to afford. I'm pretty much in this boat right now. I see value in learning Unreal if only to provide some balance to my otherwise Unity-focused work these days.

I want Unreal to succeed and do well. Not only is it a great tool that does a lot of things right, it's fundamentally important for the health of the game industry to have a set of well supported options in the tools we use. When I keep hearing people I respect tell me the only reason they aren't using it is because of the royalty situation, it sounds like a missed opportunity and one I think can - and should - be corrected.



Friday, February 27, 2015

loop labels, for your consideration

Looking back, way back, in time I think that learning the humble for loop was perhaps one of my very first programming "aha" moments as I used a nested for loop to make a grid of some sort. This was probably when I was punching in code from this book on my TRS-80, which I have somehow managed to hang on to after all these years.
My first programming book, 1979
It struck me the other day as I was looking at some code there was a familiar pattern in the code, one I have created countless times in the past and I realized there may be a simple way to improve this ancient instruction, at least for the languages I prefer to use these days: C++ and C#.

Consider these nested loops:

for(int x = 0; x < 100; x++)
{
  bool found = false;
  for(int y = 0; y < 100; y++)
  {
    if(ShouldWorkBeDone(x, y))
    {
      DoWork(x,y);
      found = true;
      break;
    }
  }
  if(found)
  {
    break;
  }
}


The pattern shown above is pretty common, as are variations on this theme where nested loops need to, for whatever reason, abort the entire loop. I have always found this to be an unpleasant pattern, only slightly better looking than the alternative that uses the goto instruction to jump out of the loop, and in fact slightly less well performing thanks to the extra if check with each iteration that a goto would not require. It is however slightly safer than goto because there is no chance of the target label getting moved somewhere unexpected, and I think this is the main reason why most people choose not to use this feature of C#/C++.

Consider this alternative: an optional label that can be used immediately following the for, continue and break keywords, which would allow the above code to be improved as follows:

for outerloop (int x = 0; x < 100; x++)
{
  for(int y = 0; y < 100; y++)
  {
    if(ShouldWorkBeDone(x, y))
    {
      DoWork(x,y);
      break outerloop;
    }
  }
}

The purpose I think should be immediately obvious - the loop label is where the code should immediately branch to, completely abandoning any number of inner loops until it finds the containing loop with the matching label.

I think this would be pretty useful.

Wednesday, October 3, 2012

Welcome!

Hello!

This blog mainly serves as a public profile, online portfolio and a way to contact me. I don't tend to write many blog posts these days so I won't make any big promises there. I will write a bit about what I've been doing lately, since chances are since you are reading this that's probably the sort of thing that brought you here.

Shortly after leaving Rockstar Games, I created Bounding Box Games LLC in October 2010 and most of my time has been spent working on projects related to this venture. Perhaps "adventure" is a better word, because it really has been an interesting change from the prior 13 years of work for Rockstar, Sony Online and EA. I've made several independent games and a slew of development related tools related to their production which, time permitting, I sometimes discuss on the development blog.

The first BBG project was a music program for the XBox called Atomic Sound which in addition to being a moderately successful XBox Live Indie Games (XBLIG) title, provided a robust sprite animation system, UI framework and other useful systems which I have made an effort to maintain and extend as a general purpose game engine code base. The next two games (MoonLander and Star Ninja) were released on XBLIG and Windows Phone 7. These extended the engine code base further with the addition of game systems and integration of the open source Farseer 2D Physics engine. For a while I was a fairly active contributor to the Farseer project, mainly helping improve the performance of various existing systems.

After Star Ninja, I put a lot of time towards the creation of a proper 3D content and rendering pipeline. The current project Thunder Moon benefits from those efforts as seen by the articulated rigid physical bodies rendered using an instancing skinned mesh system - all of which are authored in Softimage, exported using a custom plugin and eventually rendered in game with a light prepass processing (LPP) renderer.

Those projects are of course the visible ones; I haven't mentioned the many internal tools and other support work required to get these games out there. The content pipeline has been a pretty big investment and is an essential part of my workflow, supporting all kinds of useful authoring features including custom shaders, physics configuration, a dialog/banter system, and sprite sheet building among other things. The .NET services website for Star Ninja has been working reliably since launch, tracking over 7 million games played while providing players with leaderboards and providing me with useful stats and dynamic ad management. There is a publishing pipeline that allows me to quickly build a package for distribution that has obfuscation validation (which is itself an interesting little tool), WiX installer integration, version control and server updating. These are just a few of the support projects and I won't list them all here but suffice to say, I've been busy!