Some corrections are needed.

Two things from my previous posts need corrections:

1) I said that Valve has no response to UDK, including the Alien Swarm SDK. I was wrong. If you listen to the Podcast 17‘s episode where they interview the Nuclear Dawn team, the devs actually mention the Source engine, and that Valve has some sort of a royalty based scheme. It’s just that it is not public. Why?

2) I said that if you want to make a game that runs on multiple platforms, one should choose Unity. Boy, was I wrong …

It was just a matter of time before the big boys noticed that the one thing that Unity had that got them a fairly consistent user base was the multi-platform capability. And things started to happen:

Epic’s UE3 Runs Within Adobe’s New Flash 11

Udk now on MAC

Epic already caught up with Unity in terms of platforms covered (they already shipped a game for iPhone). And CryTek is soon to follow, if you’re to believe the following article.

Question is, now that the multi-platform advantage is slowly eroded by the big player, just for how long is Unity going to keep the free version of their engine crippled.


Unity, Epic and soon CryTek

What do these three names have in common?

Well, a free-mium game engine and set of tools. The rules are simple: get the engine for free, make whatever game(s) you want, sell it and fork over some of the money to the engine makers. That easy.

There are several reasons why this new way of reaching small developers is fortunate:
If you visit on a regular basis, you already noticed that mods tend to become more and more polished. The amount of contents in the “modern day mod” rivals official expansion packs, and the development time reflects that: from 6 months to 7 years. “Under the Hunter’s Moon”, an AvP2 custom campaign, took more than a year to develop. It is longer (and, in my personal opinion, better) than the “Primal Hunt” official expansion to the game.

So, naturally, the question becomes: why not make games instead of mods?

One of the barriers is being blown away: the need to code a game engine.
id Software already open-sourced idTech3, and the XReal fork of it looks quite impressive. Unity became free, then Epic announced their UDK. Now, Crytek does the same.
Although a bit late to the party, I can see a lot of modders switching to indie developers for CryEngine 3. Heck, any game engine that also has a decent set of tools WILL switch modders to indie devs. The only ‘difficulty’ here is for the developer to chose the right engine for the job: you want multiplatform? Go Unity. You want great outdoors? Go CryEngine.

This was bound to happen. Companies that want to buy licenses for the engines can still do that, and get full access, down to the C++ code. While indies get access only to the upper layers of the engine, in the majority of cases that’s enough to build the game the way you wanted. So, from Unity/Epic/Crytek’s point of view, this move will only enlarge their customer base. More people using their engines means more chances that one of those games will bring in a nice revenue. It’s a fortunate overlap of interests between small developers, who need an engine, and big developers, who want to make some money of their engines.

Demand, meet offer. Offer, meet demand. That easy. Too bad not all developers that code engines do the same.

Alien Swarm’s SDK – a weak response to UDK

Oh my, first this article, and now this new one. One could say that I am holding a grudge against Valve.

In the article I mentioned before, I was complaining that Valve had no reaction to both Unity and UDK taking by storm the indie development market. Then, I was thrilled to read the following article:

Apparently, Valve is finally giving an answer to Epic’s UDK.

Unfortunately, the answer is weak. Read ahead to find out why.

They’re almost the same.

Now, I can understand why a lot of people got excited by the fact that both the game and the SDK were released for free. If you look at the broad picture, this is what you get:

  • the Source Engine runtime, for free
  • a set of tools, to allow the creation of user content for that said runtime
  • code related to the mentioned runtime, to implement other changes in the mentioned runtime

That’s not very different from the Unity package, right? I mean in Unity you also get an editor, a free to use runtime and some code samples. Same for UDK, right?

Except for one thing: distribution rights

After downloading both the game and SDK, I looked for an EULA. Something like this, for Unity, or like this, for UDK. I was hoping to find something, an official document that would tell me “you can make games on this and sell them”.

Unfortunately, the only thing I came across is the Steam’s subscriber agreement. And points (C) and (E) say it loud and clear: “You may use, reproduce and modify the SDK on a non-commercial basis solely to develop a modified game (a “Mod”) for Half-Life 2 or other Valve products compatible with and using the Source Engine”

This means no stand alone game. And definitely not being able to sell it.

That’s why UDK and Unity still win.

Because without the rights to redistribute the runtime along with the newly created contents, you can’t really say you’re making stand alone games. You’re still making mods, albeit for a (so far) free game. And for HL2 modders, the Alien Swarm and its SDK mean absolutely nothing. Because the market the HL2 modders are targeting already own HL2.

What’s a “Pro” Feature?

We’ve all been exposed to market segmentation. You own, by any chance, a PC? Then you probably know that there are two kinds of Windows XP, a Home Edition one and a Professional Edition. Or that there are several kinds of Vista’s, or several kinds of Windows 7.

That’s market segmentation.

I can hear the Apple fan boys chuckle. Don’t worry, Apple has something similar in its stores: several kinds of iPods, and each of this kind coming in various storage space flavors. To a good extent, that’s market segmentation as well.

“So what is it to you?”, you might wonder. Well, Unity does market segmentation, but in a not-so-fortunate way, looking more and more like a “bait-and-switch” move instead. Let me explain some more:

Why was price segmentation introduced in the first place

Let’s say you are making a kardware product, called “Muffin Maker”. It does what it says, it makes muffins. Yes, these kind of muffins:

So, you just finished fixing the latest design issues, the prototype of the Muffin Maker looks great and you are now ready to roll out the product on the market. And you put a price tag on it, say 150 USD.

For a while, you get some sales. A small number of people buy it, and give you generally good feedback: “I like how the ‘berries container’ makes sure that the berries don’t get squashed while making blueberry muffins”, says Mrs. Jones. “My kids love chocholate muffins, so that’s all that I bake for them. Initially I felt that MM was a bit pricey, but now I think it was a good investment”, says Mrs. White.

“Aha!”, you scream in your office, “they belive that the product is a bit pricey. They are not willing to fork out that much money”. And you think, and you think, and you come up with a brilliant idea: “Let’s remove the berry container in half of our MMs, then sell them as Muffin Maker LE, for a 25 USD discount”. You still make money, since the costs of production are about 120USD for a full featured Muffin Maker, and 115 for one of those LE. But now, all Mrs. White alike will find it (the LE version) affordable.

That’s price segmentation. It is done to make your core product (the Muffin Makers are basically the same) available to several categories of markets. It is done primarily to get more $$.

What should be an “Unity Pro only” feature?

In case of Unity, here how things are currently standing:

  • we have Unity.
    For free, as in 0 USD to download and use it. If your company makes over 10 000 USD, you must buy a Pro license. The free version has several features disabled.
  • we have Unity Pro.
    It costs some money, but is pretty much “no strings attached”, and has all features there.

Now this might feel like a price segmenting, so let’s do a comparison between our Muffin Maker product and Unity: Muffin Makerunlike Muffin Maker1.we have two versions of the productthe ‘LE’ version of Unity has a 0 USD price tag, while Muffin Maker LE still costs some money.2.we have some featurest stripped from the LE versions of both Unity and Muffin MakerThe changes made to Unity are not all related to the end product3.Both Muffin Maker LLC. and the Unity team are in it to make some money.

Now, difference no. 1 and the resemblence no. 3 are key causes for the mismatch in the features presented in Unity vs. Unity Pro (difference no. 2).

The difference between the Muffin Maker LE and the Muffin Maker (the regular one) was how many types of muffins you could make. The LE version couldn’t make proper blue berries muffins. Or any kind of berries-based muffins.

To some extent, this is what Unity does. It has a pro version, and a ‘standard’, free version. The free one doesn’t have ‘Render to texture’, so you can’t have movies ingame. Or environmental mapping. But then, the Unity team made this decision regarding the free version of unity:

What it means is that automated builds are out of the question for the free version of Unity (there is a legit workaround for that, by the way). The equivalent for that would be like having no temperature sensor on the Muffin Maker LE, and have Mrs. White check the muffins each 5 minutes. Now, assuming Mrs. White knows about this limitation. Will she buy the LE version, or will she buy the regular one?

This is dangerous. This is why I’m saying that the marketing behind Unity looks more like a bait and switch. While it will drive some people to buy the Pro version, it will also drive others away. And they’ll leave saying “Unity is really bad in terms of usability for the developer”. Oops!

And then what do you do with the others that stick around the free version? If they are good enough, they’ll find workarounds for some of these limitations, like using AutoIt to automate their builds. When these developers become THAT good, will they really need a profiler and a BuildPlayer function? Won’t they become part of the lost sales for Unity Pro by simply sticking with the free version?

Ok, so what should NOT be an “Unity Pro only” feature?

Well, first of all, Unity needs to aim for the long term benefits of having developers using the game engine. Flood the job market with people that are efficient in using the Unity engine and all the employers will feel the pressure (from their own, freshly hired people) to use your engine. And trust me, big companies will pay for the Pro version.

And having a flood of Unity developers can be done only by leaving ALL the development tools in the free version. This means leave the profiler in the free version. Have a debugger added in the free version. And leave the BuildPlayer accessible for all, since automated builds are an important part in development. I know this, we used automated builds for an AvP2 mod and it felt GREAT.

Unity is like COM. But what is COM like?

Before staring this blog, I wrote one article regarding Unity, CATIA and the COM model. While it did show up some similarities between the three, it didn’t quite explain the whole idea behind COM’s object modeler. I mean I talk about interfaces, about components and lots of technical stuff that only show how similar he three are, but if a noob reads that article, I’m pretty sure he/she wouldn’t understand too much.

Well, this article tries to set things right.

The analogy I’m going to use has absolutely no connection to programming. You won’t hear words as “components”, “objects”. Instead, prepare yourself to enter the world of … refrigerators!
So, on our left we have our generic refrigerator. The only functionality this lump of plastic and metal has is that it keeps food cold. If you think of it, this is the primary function of the fridge.
Now, let’s assume you’re one of those people that love fridge magnets. But not these kind of fridge magnets! No. You’re a programmer trying to learn COM, so, obviously, you’re interested in fridge magnets that add value to your beloved fridge.
Let’s say that one day you find an obsure shop that sells weird magnets. You go in, looking for something … different. And there it is: The perfect fridge magnet! An LCD clock!
Now, as a smart programmer that you are, you simply put two and two together:

And it doesn’t have to stop there! You have a cheap pocket calculator? Glue a magnet on it’s back and voila! Your fridge gets another new functionality: it can now calculate stuff! And how about a barometer? That will turn your fridge into an indoor weather station. Not like the weather inside will actually change, but who cares? What matters now is that from a generic fridge you now have a super-multi-functional fridge. And you did that just by sticking extra gadgets to it!

Now, back to Unity and COM.

In terms of object modeling, that’s how COM works. Same for Unity.
In the image on our left, we have the FPS controller, that comes with Unity’s Island demo. I underlined for you two of the components that add functionality to our object:

  • FPS Walker – responsible for actually moving the player when the WASD keys are pressed. Also handles jumping.
  • Mouse Look – responsible for rotating the camera

Well, in our case, the fridge is the FPS Controller prefab. As for the fridge magnets, well, you’ve guessed it: they’re the FPS Walker and the Mouse Look scripts. And just like our fridge magnets, they’re adding new functionality to our prefab. And just like fridge magnets can be sticked to any metal surface (well, feromagnetic surfaces, if you’re a science maniac), Unity scripts can be associated to other componets as well. For example, you’ll notice that the Mouse Look script is also used on the Main Camera game object.

And this is another advantage of using a COM-like approach in Unity: you can re-use scripts. All you need to do is to drag them from the resource tree onto your object.

The only thing the fridge magnets (let’s call them components from now on) have in common is the fridge. In our case, the FPS Walker script and the Mouse Look share the object that owns them, the FPS Controller prefab. Now, this has an interesting effect, and I’ll give more details.

In the moddb article I mentioned before I’m talking also about GetComponent(). Now, the cool thing is that if I try to access the MouseLook component from the FPSWalker code:

MouseLook mouseLookInstance = gameObject.GetComponent<MouseLook>();

the GetComponent() function will return me the MouseLook instance that is associated to the same FPS Controller prefab that also owns the FPSWalker! And that’s quite allright, because we’re asking the game object to give us the MouseLook component.

Having a headache? That’s ok, a new way to create objects is a tough lesson. Still, what you should remember is that (1) you can stick existing (or new) functionality to a Unity game object by simply dragging a component (a script) to your object and (2) for a given game object, you can easily access all its components, by calling GetComponent().