Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 1, 2014
arrowPress Releases
November 1, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Recreating Unity Pro Features in Unity Free
by Alex Jordan on 02/24/14 11:13:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


Unity Pro is a wonderful piece of software, but that initial pricetag of $1,500 US is somewhat high. And if you’re working on a mobile title, that number gets multiplied by the number of platforms you’re targeting. Which - let’s face it - is a tad daunting in these days of indie market saturation and publishing-by-popularity-contest.

That means that Unity Pro might not be a prudent investment for you. However, you can still create a feature-rich, polished game with Unity Free if you keep your expectations reasonable and your design document conservative. Heck, you can also recreate many of Pro’s features in Free if you’ve got the time and the know-how!

Unity Pro’s top-shelf features come in three varieties:

  1. Making Your Life Easier
  2. Available in Free but optimized in Pro
  3. Completely unavailable in Free

Category (1) includes stuff that Pro gives you but can be custom-built in Free, like pathfinding. Category (2) includes stuff that can be roughly approximated in Free but can only be used to its true extent in Pro, like RenderTextures. And Category (3) includes stuff that Unity Free will flat-out not let you use, like native plugins or the Stencil Buffer.

That leaves Categories 1 and 2 as fair game. And here’s a few examples of what you can pull off:


Level of Detail Meshes

LODs are a simple matter of an object storing information on multiple meshes. To start, you need a MeshFilter to store mesh info and a MeshRenderer or SkinnedMeshRenderer to display it. After that, creating a simple MyLOD component to judge distance to the camera and swap between meshes is all you need to get the job done.

Component Architecture

  • References to each Mesh desired
  • References to each distance level desired
  • Do a distance check (or a cheaper square distance check, see here) in the Update loop to toggle which Mesh the MeshRenderer is using
  • Consider using ExecuteInEditMode to see realtime LOD changes while in the Editor


Unity Pro can automatically bake lighting on all meshes assigned to an LOD. To duplicate that in Unity Free, you’ll have to have multiple mesh gameObjects already in-scene, bake their lighting individually, and then toggle the gameObjects’ visibility at runtime. Tedious but doable.


RenderTextures/Post-Processing Effects

Unity Free’s lack of RenderTextures is a bitter pill to swallow for veteran programmers accustomed to complete freedom in this category. And although they can be approximated in Free, they’re not optimized and you probably can’t get away with decent realtime performance.

But they are possible, and will leave you with a nice Texture2D that you can do some post-processing on.

Component Architecture

  • Create a Coroutine named “RenderToTexture”
  • Immediately yield the coroutine with a new WaitForEndOfFrame(). This’ll ensure that the screen has finished rendering and you can do a full capture.
  • Create a new Texture2D and set it to your screen’s resolution
  • Run ReadPixels on your new Texture2D to render the screen to it
  • End the Coroutine and return to wherever you started
  • Run a custom post-processing shader on your new Texture2D


Pro RenderTextures run on the GPU. When combined with fairly cheap, optimized shaders, Pro can create consistent realtime effects at a steady framerate. On the other hand, Free's ReadPixels is a CPU-driven function, meaning that you’ll see a noticeable hiccup when it runs. That hiccup will turn into a stutter-stop slideshow if you try running it in realtime.

Also, ReadPixels is “atomic.”  That means that Unity will refuse to run it from a separate thread, preventing you from hiding the slowdown via multithreading. Besides, multithreading won’t cancel out the fact that ReadPixels is a CPU-driven function and can’t run as quickly as a GPU-driven one.

However… remember when i said that your design document should be conservatively specced?  Well, consider using this workaround in a non-realtime situation. Perhaps you might want to have your screen go to grayscale when you pause your game. If you run ReadPixels a single time to capture your screen upon pausing, run a grayscale shader on the resulting Texture2D, and then display that texture over your in-game screen, the act of pausing will hide the ReadPixels hiccup.

I firmly believe that RenderTexture-via-ReadPixels can still be effective if you get creative.



If you’re working on a mobile game, you’ll need to wring every last drop of performance out of Unity. That means that realtime pixel lighting will probably have to go bye-bye, leaving your game to the mercy of vertex lighting, all of which is handled by Unity behind the scenes.

That’s where LightProbes come in. It’s kind of like baked lighting for dynamic objects: discreet sampling of lighting at various points in the scene that are then cheaply applied to non-static objects based on their proximity. They optimize performance and cut down on lighting errors. Fun!

The not fun part? LightProbes aren't available in Free, and creating your own custom LightProbe system means overriding Unity’s lighting system and replacing it with your own via custom shaders and careful programming. Abandoning a perfectly good in-engine lighting system is a huge pain, but if you’re so inclined, here’s what you need to consider:


Although you almost never see the code behind Unity’s vanilla lighting system, it’s available for perusal. (Beast’s lighting system, however, is not.) All dynamic object lighting is handled by Unity’s shaders, and most shaders (both vanilla and custom) fall back on default lighting algorithms in Unity’s code. Here’s something you see quite often in a surface shader:



#include "UnityCG.cginc"

#pragma surface surf Lambert


The “Lambert” bit instructs Unity to use default Lambert pixel lighting code, which is actually a function buried inside Lighting.cginc that looks like this:


inline fixed4 LightingLambert (SurfaceOutput s, fixed3 lightDir, fixed atten)


           fixed diff = max (0, dot (s.Normal, lightDir));     

           fixed4 c;

           c.rgb = s.Albedo * _LightColor0.rgb * (diff * atten * 2);

           c.a = s.Alpha;

           return c;



The surface shader handles the inputs for you, naturally.

But maybe you don’t want to rely on surface shaders. For complete control, you’d want to write your own vertex and fragment shaders. If so, vertex lighting would be handled in the vertex shader and pixel lighting would be handled in the fragment shader. Either would use custom functions, or one of many that Unity already provides in UnityCG.cginc.

In fact, the ShadeVertexLights function listed at the end of that article is a great place to start. That function looks like this:


float3 ShadeVertexLights (float4 vertex, float3 normal)


             float3 viewpos = mul (UNITY_MATRIX_MV, vertex).xyz;

                        float3 viewN = mul ((float3x3)UNITY_MATRIX_IT_MV, normal);

                        float3 lightColor =;

                        for (int i = 0; i < 4; i++) {

                                    float3 toLight = unity_LightPosition[i].xyz - *


                                    float lengthSq = dot(toLight, toLight);

                                    float atten = 1.0 / (1.0 + lengthSq * unity_LightAtten[i].z);

                                    float diff = max (0, dot (viewN, normalize(toLight)));

                                    lightColor += unity_LightColor[i].rgb * (diff * atten);


             return lightColor;



You run that from the vertex shader, plug in the vertex and its normal, and voila!  Lighting information from four lights comes back, calculated by a pretty standard lighting function. The kicker, you’ll notice, is that Unity handles population of the unity_LightPosition and unity_LightAtten (attenuation, i.e. falloff) arrays on its own. So if you’re going to write a custom system, you have to design shaders with new functions that use new light info arrays and populate that by yourself.

If you’re insane enough to still think that’s something you want or need to do...


  • Write your own “custom.cginc” include file that your custom shaders can rely on
    • Variables that Unity will need to populate
      • Ambient Light Color
      • Direction Light Color
      • Direction Light Position
      • Direction Light Normal
      • Point Light Color[4 or 8 or whatever]
      • Point Light Position[4 or 8 or whatever]
    • Functions
      • PixelShade4Lights, PixelShade8Lights
      • VertexShade4Lights, VertexShade8Lights
      • Maybe Toon lighting, etc.
  • RegisterLight Component (apply on dynamic objects that you want to use the system)
    • Link to the object’s Renderer (MeshRenderer or SkinnedMeshRenderer)
    • Option to specify registration of individual materials or all materials attached to the Renderer
    • Sample lighting from nearest MyLightProbe (below)
    • Assign light positions, colors, and normals on a per material basis (This means that you can’t use any of the Shader.SetGlobal functions)
  • MyLightProbe component
    • Compiles all RegisterLight scripts and adds them to database
    • Compiles all Lights (and Ambient light) and adds them to database
    • Ranks top lights by attenuation at range to probe’s origin
    • Recompute all values if a light moves (optional)


Aside from the fact that scrapping a perfectly good lighting system is a tremendous headache?  Well, this method is also incapable of reading baked lighting and can’t tell if a custom LightProbe is sitting in a shadow.

Also, you may very well be dead before you can successfully implement all this.


Making Your Life Easier

The fact that you can recreate or approximate a lot of Unity Pro’s features in Unity Free isn’t much of a secret. After all, the Asset Store does booming business by selling you perfectly good systems that you either don’t know how to create or don’t want to spend the time creating. So if you’re ever stymied by a Pro feature that’s unavailable in free, look through the Asset Store first to see if anyone has approximated it.

Related Jobs

Twisted Pixel Games
Twisted Pixel Games — Austin, Texas, United States

Senior Graphics and Systems Engineer
Twisted Pixel Games
Twisted Pixel Games — Austin, Texas, United States

Mid-level Tools and Systems Engineer
Sega Networks Inc.
Sega Networks Inc. — Madison, Wisconsin, United States

Mobile Game Engineer
Forio — San Francisco, California, United States

Web Application Developer Team Lead


Jesse Chounard
profile image
Nice! I love these sort of things.

I wrote an importer for TexturePacker atlases, since I didn't want to spring for Pro just to get the automatic atlas generator. It's here (make sure you put it in an "Editor" folder):

James Rhodes
profile image
As someone using XNA/MonoGame, there are always people telling me I should switch to Unity because it's better and free. But no render targets or post processing unless you shell out $1500 + $1500 per mobile platform? And the only alternative in free is reading pixels with the CPU? I mean, is that a joke? Even Xamarin isn't that expensive at the business tier, and that is already overpriced in my opinion.

Unity Free might be okay for prototyping things, but I'm really not sure how people can propose that it be used to build full games.

Alex Jordan
profile image
I find Unity to be a great engine for creating a game on a budget... specifically, the lack of one. I was also disappointed to find that RenderTextures weren't available in Unity Free, but I think the rest of Unity's features and aggressive platform/engine support more than make up for it.

I'm currently working on a platform-agnostic multiplayer mobile game (any smartphone can play any tablet and vice versa), and the performance levels I need pretty much mean avoiding any fancy post-processing or CPU/GPU-intensive effects. It's an interesting case of "support more platforms would be expensive with Unity Pro, but those platforms can't take advantage of Pro's features." Whereas if I were only targeting PC/Mac/Linux, that'd be priced at a much more affordable single-license cost *and* those systems would be able to run the advanced features.

Like I said at the top of the article, if you spec out a conservative design document, you can do wonders with Unity Free.

Ian Morrison
profile image
For my own part, being on the tail end of a 2+ year game project in Unity, there's a LOT you can get done with just the free version. We built much of the game without pro licenses, and even now that we've got them we use less of the feature set than you'd think. I've only used render textures once for a gratuitous shader effect, and in our genre (2D sidescroller) real-time shadows haven't proven that important most of the time. The main Pro feature that I find myself using a lot is the deferred rendering pipeline, since my art style is fairly lighting heavy. I also end up using the extra optimization and performance features pretty heavily, since our game is a bit of a monster performance wise.

Obviously, your mileage may vary depending on the kind of game you're trying to make and the kind of engine features you require, but for many games you could build them start to finish in Unity and not suffer too badly for it, especially given the general flexibility and power the engine gives you. I could easily imagine our game having been made without pro, albeit at a reduced lighting fidelity and framerate.

Wes Jurica
profile image
Having only been in game development for a year and an owner of $4500 in Unity licenses, I think I qualify as one of those "people". You get more than an engine with that money. The value of the community that comes along with it cannot be overstated. Add that to the Asset Store and it is a great value. I could have made the same game with MonoGame (probably) but it surely would have taken me much longer to complete. Instead of still toiling away recreating the features Unity has out of the box, we shipped the game almost 6 months ago and recouped our investment 20 times over.

Jed Hubic
profile image
So we just made the switch from Monogame to Unity and while you do lose some stuff, I'd say Unity was a much better shift. Have you tried writing cross platform mgfx post effects in hlsl in Monogame? Not fun. What are you needing the multiple render targets for? I've relied on them heavily in the past but I guess I haven't hit that hurdle with Unity. If you shift your mindset that you're making a game from a different approach it probably won't be too bad. Monogame is pretty baller, but for crossplatform Unity is even better (I'm a free user with a bunch of extensions).

James Rhodes
profile image
It's reasonably easy to write HLSL shaders in MonoGame, but like all shaders you need to frequently test each change to make sure it works. I don't find this to be much of an issue.

I primarily build my games with code, I set up and configure everything with code, mainly because I'm a programmer but also because it allows me to be precise about things should run. Currently being on MonoGame/Protogame, there's some really fundamental things about Unity that would have to change to bring it on par with what I currently have:

- Some form of "build in code, skip the designer" mechanism. As a programmer I don't particularly care or find useful the Unity designer; I need an engine that can support building everything in code.
- Fixing the bastardization of a thing they call C#. I mean, it's just horrendous. No namespaces? Default constructors only and weird Awake methods? Because constructors don't behave normally, that also means you can't do dependency injection, which means things like go completely out thé window.
- Full, proper Linux support for both the engine and development. We're moving to a world where Linux support is not optional (see: anything that Valve is doing with Steam)
- Render targets in free. I mean, seriously, this is basic, trivial, graphics API stuff.
- Some pretty strong assurances that we're not going to be stuck if Unity goes under, locks up essential features or otherwise puts us in a difficult position. We've been there before with XNA and we now use a completely open source stack so there's a 0% chance that any middleware can impact our game development in such a way. More specifically it would need a clause that states the source code is made available if the company files for bankruptcy or the engine is no longer freely available in it's current form.

That's basically the minimum requirement to bring it to the same level of usability and stability of what I currently have. I'm not particularly interested in the "but Unity does this other random thing" argument because in my eyes, these are critical requirements and they're currently missing, regardless of what other things it might do.

Wes Jurica
profile image
And while that may be true for you, maybe you shouldn't take your own requirements as the end all for others. By all means enjoy Monogame but, it's pretty clear that thousands of developers have shipped games with Unity and those numbers continue to increase. Even AAA studios are on board.

James Rhodes
profile image
Well I'm not taking my requirements as "the end all for others"; I make it pretty clear that these are my requirements.

But not a week goes by when some other developer doesn't say "hey you should use Unity", believing that Unity is somehow perfect or would solve all my problems. What I'm trying to do is point out that while Unity has things that some people find useful, it's not for everyone and at this point in time, if someone's not using Unity, they probably have a good reason (or several) for not doing so.

Wes Jurica
profile image
The last sentence of your original post suggests otherwise.

James Rhodes
profile image
My current game engine has a set of functionality or features that Unity does not have. I consider these features to be critical when I am using a game engine. But that's *me* using a game engine that meets *my* requirements.

If people are making commercial games in Unity Free then that's good, but I don't believe that the free tier is appropriate for all games, and in some cases (such as mine) I don't believe Unity is suitable at all. You yourself admit to purchasing $4500 to get additional features, and I doubt very much that AAA studios are using the free version either.

It's about using the right tool for the job; if Unity Free works for you developing commercial games then that's fine. But as I stated in my original post, knowing that the free version is limited in areas such as the ones mentioned makes me doubt that Unity Free a good choice to be recommending to people if they're likely to run into the limitations.

Kailas Dierk
profile image
Your problems with unity seem a bit misguided / outdated.

- "build in code, skip the designer" is quite possible. You can do just about everything in code and the rest can be done in the editor without a designer.
- Unity has had namespaces for a while now.
- Awake methods can be a bit annoying at times but you can always design around them. For example, to effectively create a constructor for a script, give it a public static Create() method that takes the parameters you would give a constructor and returns an instance of your script after doing whatever your constructor would do. Unfortunately that means you can't use the readonly keyword, but it is still a functional workaround.
- Unity can build to Linux, but beyond that I have no idea. To me, Linux support is entirely optional.

James Rhodes
profile image
As I understand it, you still need to go back to the designer to run the game. Which means I have to switch focus of what I'm doing on a frequent basis to something I don't even care about, just so I can test my change.

It's good to see that they've added namespaces (although last I heard these do not work with behaviours). The Create() solution still doesn't permit proper dependency injection. For dependency injection to work in the most accepted manner (other than property injection), you need to have properly working constructors. This is required to ensure that you can not get objects into a state where their dependencies are not satisfied.

As I run Linux on both my development machines, without Linux support on the development side I pretty much can't develop the game (without switching into Windows all the time).

Kailas Dierk
profile image
It depends on what you mean by "go back to the designer". You have to go back to the editor to run the game (from your IDE), but its not like you aren't allowed to click play just because you're a programmer. You don't have to "switch focus" of what you're doing to test code changes in unity than in any other engine, you just save your files, change to the unity window and click play.

Unity always supported namespaces for non-MonoBehaviour classes (or it did in 2.something when I first used it), but I think they only allowed them for MonoBehaviour derived classes in 3.0.

Amir Barak
profile image
Unity is a good solution for some things and not others as James said before. I work with Unity alot and also my own tech and whenever someone asks me for my opinion I very rarely recommend Unity to be honest.

For all of its benefits Unity has some serious drawbacks and personally I find it (like most general purpose engines) quite, um, lumpy I guess is a good enough description. In the end all general purpose engines are the antithesis of lean development which makes things more difficult, not easier.

Juan Mora
profile image
In regards to your complaint about constructors and Awakes, do you know that not all your classes have to inherit from MonoBehaviour, right? Here, in our projects, about 5% of our classes are MonoBehaviours, but all other classes are plain c# classes, where you can create any constructor of your liking, make dependency injections, and so on. You are forced to use only one MonoBehaviour, which will be in charge of starting code execution, but from there, you can design your program freely.

Devin Horsman
profile image
You should probably consider using GrabPass and UsePass and a fullscreen quad for some simple postprocessing effects.

Alex Jordan
profile image
I could've sworn that GrabPass was Pro-only. Am I wrong? If so, you've just made my day *and* I'll have to quickly update the article.

EDIT: Near as I can tell, GrabPass is still Pro-only.

Shane Dielschneider
profile image
If you are targeting iOS 6+ you can use frame buffer fetch shader extensions to do simple (single sample) post-processing effects. It's most useful for greyscale/colour-mapping, and custom blending overlays (vignette or noise grain). I've also used it for a full-screen cross-hatching effect. It's very fast; at least as fast as render textures and possibly faster since there is no screen texture memory to sample from. It operates directly on the frame buffer.

It's also possible on Android, but support is not as widespread as it could be. As far as I know only Nvidia Tegra implements it right now though it could be supported on most mobile devices out there. The hardware is willing, but the graphics drivers are weak.

It is not supported on desktop at all as far as I know.

Alex Jordan
profile image
I'd never heard of this. Do you have any details on it?

Maxime Bolduc
profile image
Personally, I find the Unity Pro price tag to be actually really cheaper than any other engine which offer at least the same amount of tools.

Let's see a comparison of the recent/upcoming releases :

Unity Pro :
Currently, buying a license of the upcoming Unity Pro 5 include a license for the current Unity 4 Pro so I consider Unity Pro 5 as Unity Pro 4.
An mostly unnoticed thing about Unity is that people think that everyone of their team would need Pro, which is wrong. You only need one computer with pro to release a game with all the Pro features. You can easily build up assets packages with everything set up in Unity Free and add the small touch-up on a single computer with Unity Pro. (You can't bring things back in Free from Pro, but you can bring thing from Free to Pro)
Everything (script-wise) in Pro can be prepared in Free and even the "error detector" works in free with pro-only feature. It only doesn't show visually and it might show a message like "This isn't supported in free". It will still work if you transfer it to the single Pro computer.
So, with a well oiled and prepared workflow, you pay 1500$ for PC, 1500$ for iOS & iPhone, 1500$ for android (if you aim for every Smartphones & tablets). You already got the Black Berry 10 and Windows Phone (+app store) included with the basic PC Pro version.
Also, the upcoming Unity 5 include GLWeb incorporated HTML client release. (Meaning it now include Flash, Unity Player (for better optimization & compression) and GLWeb (no plugin or client needed) with the HTML5)
Total of 4500$ and you're good to release on any PC/Mac, Tablets and Smartphone. You also don't have to program the different version for different OS (you still have to plan things accordingly).

There's also the 75$/month subscription. Personally, I do find this possibility a bit too high as it doesn't include any plugin or even the Team license. It's almost made for short-term projects like 3-4 months to be profitable.

Cryengine :
The Cry Engine is a really great piece of software to PC/Mac releases. With a lot of work and some really hardcore programmers with skills with GLWeb, you can release browsers games. You got 2 options : Subscription which cost 9.95$/month per computer. (There's no "free" version so any team member who have to work with the engine must have a separate subscription) Also, note that this sub require a constant connection to work. You also got the licensing option which include either royalties or a heavy industrial cost. (Both ways come up to a lot higher than Unity) The subscription model might sound great, but it comes with a special rules : as long as you're selling a product made with the engine, you're required to keep at least one subscription. So if you ever want to keep selling the product, you're chained to that contract even if you don't work with it anymore.

Unreal Engine 3 UDK
Free to use, comes with a 5% royalty contract on incomes & advertisement (if you sell advertisement in-game, the royalty affect it too) related to the game. The engine is now unsupported and won't be updated anymore as stated by Epic corps. It does include a big devs. community thought which offer great help for those who show commitment at being serious in building their game.

Unreal Engine 4 (include UE3 until the final release)
Cost 19$/month per computer, but include tools for every ports/consoles. There's still the 5% royalty contract on incomes & advertisement. Unlike the Cry Engine, selling games made with the engine doesn't force a subscription to be active. (as the reason of their 5% royalty)
For a standard production workflow, its cost is around 456$ per computer + 5$ for every 100$ sold.
(The 5% royalty isn't on profits, but on sells, meaning the budget should be calculated as : (Incomes - 5%) - Cost of Production & release = Profits
From a bit of calculation, UE3/4 cost more than Unity if, on a 2 year-long project, you have 3 members or more using the engine and sell for more than 31 320$ in games per year. So, if you sell your game for 10$, it's reached once you sold 3132 copies.

That's the reality behind the cost. Unity is cheap as long as you go with the flow.