Unity, AssetBundles, C# and Co-routines

I spent a day figuring out how to do the asynchronous load of an asset bundle in C#. Below is a minimal workign example along with some explanation:

using UnityEngine;

using System.Collections;

public class AssetLoader : MonoBehaviour {

string assetURL="http://localhost/UnityAssets/WorldWizards/TileSets/Tileset_tin01.unity3d";

// Use this for initialization

void Start () {

Debug.Log("Start");

// This is a Unity method that hijaks the .NET co-iterator functionality and

// uses it to create a psuedo co-routine

StartCoroutine(LoadAsset(assetURL));

}

//This is a co-routine method. Co-routines must return the IEnumerator interface

//This is because .NET doesnt really have co-routines, it has a co-iterator. Unity

//cleverly hijacks that to create a co-routine. If you need more information, you

//can try reading the micrsoft docs on yield return, but they are hairy

IEnumerator LoadAsset(string url){

// This call utilizes unity's asset cache to avoid reloading the same assets over again

// If you dont want asset cahchign replace it with:

//WWW www = new WWW(url);

WWW www = WWW.LoadFromCacheOrDownload(url,1);

// This is how you return from the co-routine. The www needs to be passed

// back as a parameter. The .NET mechanism hides this within a synthetically produced

// IEnumerator as its first entry in the enumeration but thats hidden inside of

// StartCoroutine and you'll never see it.

// Whatever is returned must inherit from the base class YieldInstruction

yield return www;

//THis code is run after the www has fetched its data or errorored out

if (www.error!=null){

Debug.LogError(www.error);

Debug.Log (url);

} else {

Debug.Log ("Done");

AssetBundle ab = www.assetBundle;

Object[] tilePrefabs = ab.LoadAll(typeof(GameObject));

foreach(Object obj in tilePrefabs){

Debug.Log (obj.name);

}

}

}

}

Unity's co-routine mechanism is interesting. theoretically you should be able to use it to do just about any kind of co-routine coding. The hitch is that they have hidden the details of YieldInstruction. This goes along with a general semi-crippling philosophy in Unity that they only want you to use the tools they give you the way they already thought they would be used.

Its too bad, because there is a lot of power in the Unity codebase that is completely blocked off from use by the developer.

Top Down Design/Bottom up implementation

In my previous blog i made a case for management as a service profession. And that is something I really believe.

Like any good idea, however, it can be taken to bad extremes. In this post I thought I'd address that.

In traditional procedural programming, we have a concept of "top down design/bottom up implementation." What this means is that you start at the general goal and break it done into sub-tasks. You then break each of those sub-tasks up, and keep going until you hit a level that "feels right" for implementation. (There really is no hard and fast rule for what this is, knowing it when you hit it is more art then science.) Then we start building the software starting at that bottom level and working our way back up to the goal.

This results in a software design that is well focused on the goal, but also is built in clear and separable layers. Top down design is a matter of designing software functionality and interfaces to that functionality. In today's object oriented world it can be seen as a form of "encapsulation' but it is a very specific form that leads to software with some very good properties. Should any individual layer prove to have an issue it can be fixed or replaced with no impact on the layers above it and below it. Higher layers can be stripped away without sacrificing lower level functionality. Finally, each layer can be created by people with the best understanding of that layers' functionality.

An engineering project can be, and I will argue, should be designed in the same way. At the top are those defining the business goals. Beneath them on the tree are one or more layers of architect who take the output of the management layer above them and decompose it into goals for the layer below them until the decomposed parts of the design finally arrive at the implementing teams.

Such layered project design has all the advantages of layered software design. Failures on part of the process do not directly impact other parts of the process below them and impact above them only so far as the architected interfaces need to change. It also focuses each participant's efforts on the area where they add the most value to the project.

In my previous blog I talked about the management side of an engineering manager's job, but many people managing engineers are also engineers or architects themselves. And this calls for a different set of skills and approaches then the management side.

Non-engineering management can often get confused and think that "empowering the workers" means asking every engineer's opinion on everything. Or worse, asking everyone's opinion on every functional part of the process from engineering to art to game design.

This devalues the very expertise you probably hired these people for to begin with and creates a whole lot of confusing noise for upper management. In such an environment, decisions become highly politicized and those who can "sell"(1) what they want in terms that make the most sense to those who often know the least-- upper management-- prevail in defining the entire project.

Part of empowerment is authority. And if you give everyone equal authority over everything, then noone has authority over anything. A football team where everyone is trying to play quarterback doesn't get very far down the field.

So, empower your people... but empower them to do *their* jobs, not everyone else's. Trust that you have hired the right people for the right positions and let them play them without undo interference from others with other functions. That is true empowerment.


(1) Engineers have a technical term for the act of sales. We call it lying. I have *no* tolerance for engineers who deliberately color the information they are passing up in order to get a desired reaction and, if i am allowed to, will fire anyone I catch doing it. That is the flip side of giving some one authority and your trust. If they violate it, they are gone. The kind of management i do calls for honest and open communication, not political positioning.

How to effectively manage professionals

Looking around for my next gig has made me really think about how I manage professionals and why. If you haven't seen this TED talk, and you manage professionals, you should.

http://www.ted.com/talks/dan_pink_on_motivation.html

On top of Dan's excellent anaylsis, let me add a few observations from a good deal of experience on both sides of the management fence:

(1) If you have a system, and its getting lousy compliance, the problem is *the system* not the employees.

(2) If you have a problem employee, 90% of the time what you really have is a mis-match of employee to situation. It is far less wasteful and generally more productive to try to fix the situation then to try to "fix" the employee.

Both one and two above are based on a simple and true premise. Its one Dan talks about in his work. Its that people are intrinsically motivated. Most people really want to do a good job. Rather then the typical management view of "if someone isn't doing a good job then they don't care enough", I propose that 90% of the time if someone isn't doing a good job its because something is in their way and they are at least as frustrated by it as you are.

This leads to my third observation:

(3) Self-organization is the most powerful solution to (2) in your arsenal.

I have seen this over and over. If I try to over-structure a team, I make mistakes. People struggle with the roles I have assigned them. Some do well, some not so well. This is not surprising. After all, all I really know about them is a resume and some short conversations.

HOWEVER they get to know each other very well very quickly. They spend 8 hours a day problem solving together. Left to their own devices they inevitably come up with better solutions as to who is suited to what then I could. Furthermore, their solutions are fluid and can change to meet changing requirements.

Which leads me to my most important point....

(4) The single most detrimental thing to professional productivity, is too much management.

Its wasteful in that it requires a lot of management time, and its wasteful in that generally all you are doing is getting in the way of your people. When I have a team spun up and functioning, that team takes half an hour a day to manage, and (depending on its seniority) 5 to 10 hours a week to coach. Thats it.

If you think every team needs its own manager, you are doing way too much management. 9 women cannot make a baby in 1 month, and 9 managers can't make a baby at all! In fact, put even one "manager" in the room full time directing and grading a couple trying to make a baby and its the rare couple that can manage to achieve the goal.

The old school of management suggested that the best motivators were fear and greed. As Dan points out, that works great for assembly workers, but not for professionals.

The best motivators for professionals are autonomy and trust. The *first* job of a manager of professionals is not to manage the workers, but to manage their environment such that they can work effectively.

This isn't to say that a team should not be directed, but the most effective direction is in the form of engineering goals to accomplish not ways to accomplish them. A team that feels empowered will come to you, in most cases, if they are unsure of how to proceed. And such "event driven" management is far more efficient for both sides then "polling."

For the cases where they don't realize they are headed into trouble, thats what monitoring is for... but that monitoring should always be a light touch. A peek over the shoulder of a mentor, not the drumbeat of a task master.

In my case, I use a white-board based scrum burn-down chart and it takes 10 min or less at the end of the day to discuss and update it. The goal is not to grade them on productivity, but simply to know what is getting in their way and to adjust estimates as we understand more about the problem at hand.

The modern manager needs to serve the company's greater goals by serving his employees needs for both direction and an environment in which they can do their best work. And a manager with time on his or her hands is a manager who has succeeded in those goals. A constantly busy manager, on the other hand, is one who is floundering.

In short, modern effective management is not a position of mastery, but of service. And true service means doing just what is helpful, and then getting out of the way.

My wife, the theologian, would say someone told us this 2000 years ago. Its time we listened.

For those with no memory....

I get really annoyed when people start mouthing myths as facts, particularly when they fly *against* all actual facts.

That the current deficit is somehow due to the democratic party or their priorities is simply and obviously not true to anyone who actually looks at the facts:


Fact: We had a national budget surplus when Bill Clinton left office.

Fact: The current debt is *entirely* due to George W Bush fighting two wars on credit.

If you don't believe me, look it up in any honest and unbiased source for historical news.

Business, F2P, MMORPGs and basic math

My past two columns have been digging into Zynga numbers from their S1 statement to see what we can learn about the real F2P business. Today, I'm going to do some basic math with the, Don't worry, its nothing worse the multiplication, division, addition and subtraction. just those simple tools can generate some very interesting results.

The big squawk in the MMORPG space right now is about MMORPGs turning to F2P/Micro-transaction models. Its being hailed as some great new trend, but I've always maintained that the economics were fairly clear. That this isn't a viable way to make money in this space. Why then do it? Because, I contend, in all these cases you have failed MMORPGs with sunk costs to recover and some income is better then none.

With the hard Zynga data, we can explore this topic a little bit better.

Two columns ago, I dug out of Zynga's numbers a clear data point-- that Zynga grossed $3.21 per year per active account in 2010; Last column, with a bit deeper analysis, I concluded that they see a raw margin over operating expenses of about 20%. This means a net before marketing and such of about $0.64 per active account.

So, lets make a few assumptions:
(1) Zynga is the master at this and represents a best-case long term return (a fairly reasonable assumption i think.)

(2) Your MMORPG costs $40M to develop. (Age of Conan was $40m as per http://forums.ageofconan.com/showthread.php?t=149585&page=3, Wow cost $68M to develop http://www.raphkoster.com/2006/06/13/what-wow-cost/. So that seems conservative.)

(3) Your MMORPG has a life-span of 5 years and maintains peak usership for all 5 years. (A very generous assumption.)

(4) Your MMORPG has no more cost of operation then Zynga's casual games and can reach the same profit margin. ( A very very generous and almost certainly false assumption.)

In this perfect storm, how many users does it take til you break even?

Well 20% of $3.21 is about $0.64 a year per active account. Over 5 years thats $3.21 again for the 5 years (not surprising, 5 is 20% of 100).

$40M/3.21 = 12,461,059

SO to even make back your investment in this model, you need to sustain an active user base of almost 12.5 million users over 5 years.

Seen many MMORPGs do that recently? WoW only has 11.4M current subscribers, took years to get to that point, and spent a lot of money on marketing in the process that isn't accounted for in the above overly-generous model.

Real F2P MMORPGs are sometimes a desperate way to get some revenue out of a failed product with sunk costs. But as a way to even break even its a fantasy, not a business model.

More Zynga Analysis - Profit margin

One of the unanswered questions for a long time has been "how much money does Zynga actually make?" They have been happy to release gross figures, but not net. What is their actual profit margin. A friend of mine used to joke "We lose $10.00 on every sale but we make it up in volume!" Obviously, it doesn't matter HOW much money comes in the door if it costs you more then you are taking in to get it.

This is particularly highlighted by the revelation of my last blog. Zynga is taking in about $3.00 per active user account per year. Now, the economics of online help here a little. Your operational costs are mostly based on concurrently connected users, or CCU. Each concurrently connected user has a cost associated with supporting that user's online session. So its really the return per CCU that matters in your final economics.

It is a rule of online entertainment that your peak CCU is 5% to 10% of your total active user population. So, lets be generous and multiply Zynga's $3.21/yr/active account by 20. That gives an actual income of $60/peak CCU/year or $5.00 per peak CCU/month.

Thats *not* a lot of money to runa service on. A $5.00 per month subscription MMO generates $100/peak ccu/month by the same math. a $15.00 one generates $300 per peak CCU/mo. So, how much of that $5.00 a month is beign spent to get support that user? What is left is what is called the "margin", and thats where your profit comes from.

We can get a rough guess from this, more complicated chart from the S1:




In particular we are interested in this line, gross revenue:



And this line, which is profit after operating expenses:



What we can see from these charts is that, in 2010, Zynga took in $597,495K or just about $597.5M.
Not bad, but what was left after expenses? from the second line we see that, before taxes, it was $127,059K or about $127M.

From that, we can compute a rough margin, using the formula margin% = 100*net/gross. Thus Zynga had a profit margin in 2010 % of about 100*127/597.5 = 21%. Thats not a great margin, but its not razor slim either. As long as they can hold their costs even they aren't in a bad place.

And there is the rub. Because entertainment that stays the same bores its audience and dies. Every other platform and niche in game playing has seen a fairly rapid escalation of complexity and cost in games. The casual space is not likely to be any different. So, can Zynga meet the future challenges it faces on $5/ccu/month? Its a good question. if i had the answer I'd be making a lot more money then I do now (which isn't too shabby as it is.) One thing is for sure, you cant run a game as complex as a modern MMORPG on that. Not without drastic compromises in security.

Another interesting thing emerges from the Zynga documents however, which is that in 2009, with $127M of income, they actually *lost* money. Now a lot of that may be attributable to marketing spends to get themselves to their current $600M of revenue. But if 2010 is benefitting from last 2009's deficit, it calls into questions how sustainable the current margin really is.

No easy answers, but an interesting read. One thing is for sure-- this is not a financial model that supports server-heavy game designs. Unfortunately, those server heavy designs are also the only way to make complex games secure.

All in all I suspect it will be an interesting future for Zynga.

Real Zynga Numbers

There has been much speculation about Zynga's numbers over the past few years. They gave out tantalizing tidbits but never enough to really know what they were making. As the acknowledged leaders of the F2P space, this is important information and, in the absence of real information, speculation ran wild.

However, in order to make a public offering, you have to "lift the skirts" as they say and so, buried deep in Zynga S1 filing with the SEC are these interesting tidbits:


This is a chart showing Zynga's gross income. The magic bar is the darker blue "revenue" bar as thats the actual money they took in.

This by itself is not much news, but when combined with this next chart, also in the document, it starts to paint a picture:



Looking at a total 2010 income of $698M and an average DAU of 217M, thats about $3.20 per active user account per year.

Honestly, thats better then I thought, though obviously a lot less then the $60 - $180 per account per year a subscription MMO returns.