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 moddb.com 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:

No.like 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.

To DRM or not to DRM

The first DRM scandal was related to SECUROM. There were two things people complained:

1. the fact that SECUROM uses root-kit technology, thus making uninstalling it a matter of formatting the hard disk.
2. the fact that games installed it without at least notifying the users.

The second DRM scandal was related to Ubisoft’s Internet connection based DRM. There were a good number of arguments brought against it, I’ll just list some:

1. the servers themselves are a single point of failure. They might not always be online, or they might be attacked. There is no immediate failsafe measure.
2. internet connections are not 100% reliable. If you have a wireless connection, things are even worse. Kicking the player out of the game if the connection drops is too harsh. Again, no failsafe measure.

So, naturally, everybody asked themselves the same question: to DRM, or not to DRM.

And my answer to this is, without any trace of doubt in my mind, a rock-solid, unpleasant and hard to avoid … “depends”.

If you feel cheated from a YES/NO type of answer, put your heart and emotions in the freezer and read more.

Let’s start by splitting the question into:

• What types of games should be DRM-ed?The initial proposal is to DRM everything. But you see, once the code arrives at the player, there’s absolutely no guarantee that the game will not be cracked. Or to put it the other way around, once somebody else besides you has acces to the binary code, it will be cracked.

  You may say that “well, still, it’ll take them a while to devise a good crack”. But eventually they do. And since tough DRMs WILL (not might, WILL) hurt customers, that’s not the way to go anyway.

  What does that mean in terms of what games should be DRM-ed? Well, what I’m trying to say is that DRM and Single Player games don’t make sense. All of the game’s components are in somebody else’s hands. So, I dare say, don’t bother adding DRM to Single Player only titles. Later on I’ll mention some exceptions to this, but the main idea is “SP = No DRM”.

  If you think that this “SP = No DRM” approach will lose you money, there are plenty of examples that say you’re wrong, and that “SP = No DRM” actually works:

  The Humble Indie Bundle event made over 1.2 million USDNow that we narrowed down our range of games, we can properly address the next question:

• How should DRM be implemented?Let’s try to negate the complaints I listed above, in a weird attempt to obtain some key features of a good DRM system:
  • do not use root-kit technology. Make it easy for the player to ditch the game from their computer.
  • have failsafes. If the DRM mechanism relies on components that can fail, have failsafes.
  • avoid the single point of failure. Strike that one out, since this kind of philosophy should be applied everywhere.

  And since we narrowed down our search to games that have an online component, here is one example of well implemented DRM:

 

• GAME = DRMThe DRM system IS ALSO THE GAME. No root-kit used. No need for a failsafe, since a downed server doesn’t mean that the DRM denied you of an otherwise functional game, but it rather means no game.

  This obviously works best for MMOs. In MMOs, by the nature of the game, all customers share an important component of the game, the servers.

• Keep a database of your customers (Steam approach)This is how Steam and the other digital distribution platforms work. They know if you bought the game or not.

  The way it works for MP game is as follow:

  • the customer enters his credentials in the Steam client
  • the customer then starts the game
  • when connecting to a game server, the game server sends the customer’s credentials to the Steam server. If they check out ok (in terms that the customer does own the game), then the customer is allowed to join.

Both approaches share some similarities:

• the game developer/publisher has some control over a part of the game. In the case of MMOs, the game server. In case of (b), you own the master server, that ultimately decides if a player can join a game server or not.
• the DRM mechanism is implemented using those pieces of the game. No root-kits on your PC. No hardware scan that then limits the number of instals; heck with Steam, you can install the game on an unlimited number of machines. The key here is that you are not allowed to play simultaneously on more than one.

That’s the deal. Use a server-side DRM mechanism for the multiplayer components of a game. Don’t bother do add DRM to single player games, since all the software components needed to play the game will ultimately reside on the customer’s machine.

I mentioned an exception for DRM in single player games. That exception is: add DRM (1) if you already have it developed for other games and (2) it is a trivial effort to incorporate it and (3) it is light in terms of checks (think Steam, not SECUROM).

Valve is about to get an Epic ass whooping …

I appologise to Valve’s fanboys for the offensive nature of the title. I know it hurts, but that’s how the latest news felt like:

“Steamworks now integrated into UDK“

I can already hear you shouting: “But that means that actually Valve bitch-slapped Epic, not the other way around!”. Easy there! Although not a Valve fanboy, I like plenty of things from this company to be on your side on this one.

But, what if I am to tell you that development teams think about shifting from the Source Engine to UDK? Or the fact that Valve still didn’t match the offer made by both UDK or Unity?

It all started one year ago, in 2009. Unity released its engine for free. It was good news, despite the fact that the free version of Unity has some limitations (of which, by the way, some are actually plain stupid).

Then Epic did something … epic. It released it’s runtime at a very cheap price for indies. Don’t get me wrong, Epic did that before with UT2k4’s runtime. What made things different this time is that the Unreal guys allowed people to make and sell games based on the UT3 runtime that we now know as UDK. That’s the epic part right there!

Other than that, both companies have similar offers: binaries-only access, low (99 USD in case uf UDK) or inexistent (in case of Unity) prices, tools, examples …

So, when I saw that Epic, a company that once said it’s shifting focus from PC towards consoles, is now following the footsteps of Unity, I told myself: “Wait until Valve sees this! I bet they’ll release their Source engine (the non Orange Box thinggie) immediately!”.

So I waited … and waited … and waited … insert crickets noise here … and waited.

And nothing happened.

No, I’m lying, something did happen: UDK incorporated Steam.

You’ll shout out once more: “But Valve will be making money out of this!”

And I shout back: “That’s small potatoes!”. Here’s why Epic gained (and still gains) from this “let everyone use our engine” approach:

1. Some money. Again, this is small potatoes. In order for this to matter, the next BIG thing on PC gamming MUST come from indies. I don’t see this happening any time soon.
2. Fame. This matters more, actually, because the hidden message here is “our engine is so neat everyone can use it”. Plus, it puts Epic back in the eyes of the indie-wannabe modders. And this matters because Epic will ultimately gain something much more important than the above two:
3. Developers.
   I’ll spend a bit of time explaining why this is important:A game lives for as long as the community built arround it keeps playing the game.Same goes for frameworks (game engines in our case): it lives as long as people develop applications (here games) for that said framework. There is a reason why Steve Ballmer kept shouting “Developers, developers, developers”:

   Having developers on your platform means that cool applications will appear for it and people will buy them AND the platform.

   And another insiduous effect is that a good deal of the gamming development workforce out there will be competent in Unreal. So their future employers will feel a stonger push to use Unreal in their products.

So you see, Epic is playing for the long term, trying to get their hands on the best asset out there, the development teams.

If for one second you belive that there are no teams switching from Source to UDK, well, think again:

http://www.moddb.com/mods/age-of-chivalry – a Source based mod, released in 2007

http://www.moddb.com/games/chivalry-battle-for-agatha – an UDK powered game

And it’s the same team. They once worked on a mod for source. Now they’re making their game for UDK. Apparently, moving the art assets from one engine to another is fairly simple, if you still have the original, engine-independent, files. Coding can be done in a reasonable ammount of time, especially since the Unreal community doesn’t seem to lack coders.

As for UDK using steam? Well, that’s just another feature that makes UDK attractive. The irony here is that they’re using a Valve product to acheive that.

Gabe, I know you’re not dumb. And you know that I have nothing against your company. I love how you make sure that ownership of the game is not limitted to a platform. I keep using Steam as a perfect example of a good DRM.

But you should look int this thing man. We know Source is not that straight forward to use, but people are willing to go pass that. All they want is an opportunity. Give them that opportunity, especially since your company always had a great modding community.

Otherwise, when the “game as a service” concept comes to fruition, you might not have enough developers behind it to keep it alive.

Be a developer, don’t turn into a publisher that sometimes develops games

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().