Why everyone is wrong about Sony and GaiKai

There has been much trumpeting of the Sony purchase of GaiKai as the great coming of remote game playing (called "cloud gaming" among the over-hyped press.)

The thing is,  GaiKai isn't a "cloud gaming service."  Why did Sony buy GaiKai and not OnLive?  I want to suggest to you that it is because they don't want a could gaming service.  They want something else, something GaiKai very cleverly foresaw.

Onlive is a cloud gaming service.  Their value proposition is to compete head on with local gameplay.

The problem is, they really cant.  All the economics are against it.  You still need the computer that used to be on the player's desk, they just moved it to the machine room.  No expense saved there.  Add to that you still need a thin client at the user's end and you have additional hardware expense plus the cost of the bandwidth to transmit the data.

So, OnLive is inherently a more expensive way to play a game. Is it at least a better experience.  The answer is no.  Serious lag is a reality of any remote play over the internet.  MMORPGs and other games designed for that environment use a variety of techniques to hide most of the lag, but these techniques have to be built into the game.  This is why MMORPGs are played differently then local twitch games.  Onlive is trying to run vanilla games designed for local play remotely and thus can do none of this.  Because of bandwidth costs and constraints, the visual quality of an onlive game is also seriously impacted.

(For some good real world measurements, take a look at this article.  Keep in mind though that latency is very dependent on your location on the net relative to the host computer.
http://www.eurogamer.net/articles/digitalfoundry-face-off-gaikai-vs-onlive
)

So, in the end, the value proposition for this "cloud gaming" is more expensive gameplay in inferior quality.  It is no wonder it has failed to take off.

But, I started this article by saying GaiKai is not a cloud gaming play, and its not.  From the beginning GaiKai positioned themselves not as a replacement for local gaming, but as a way to do live game demos over the internet.  The use case of GaiKai is for digital publishers to drive digital sales by solving the one problem with the digital download store-- that you can't touch the product before you buy it.

Microsoft, with XboxLive, and Valve, with Steam, have shown that there is big money in digital distribution.  So much so that the biggest traditional publisher  in the industry, EA, has launched their own online store and has stated publicly that they expect the business to go all digital eventually.

Sony's entries in this space have been lack-luster.  But GaiKai gives them a key differentiator for their next run at it, likely with the PS4.

And this is most likely why Sony bought GaiKai.

Lies my politicians tell me...

Myths are an interesting thing.  They play off the "familiarity bias" in psychology.  Hear something repeated often enough and you tend to accept it without thinking very critically about it.  Some myths occur deliberately through advertising and other directed media.  Some occur spontaneously through "meemes".

Modern politicians and lobbyists have tuned this to a fine art and do their best to exploit all of the myth-makign opportunities at their disposal.  The thing is, myths are most often false or incomplete.  They survive because people hear them and repeat them without ever really questioning them.

Even the most skeptical of us can fall prey to the power of the myth.  All it takes is a moment's sloppiness in thinking and it is through our barriers and into our mental body of 'facts'.

I'd like to take a moment in this campaign season to stop and explore two prevalent myths today.  I ask you to consider them under the light of real critical reasoning.

Myth 1: Insurance companies exist to pay your medical bills

This is total nonsense.  Insurance companies are companies.  The exist to make profits for their owners.  The greater the profits, the better the business.  Paying your bills reduces those profits.  

The fact of the matter is that the entire system of medical reimbursement exists to give the insurance companies as many reasons as possible to not pay your bills and still remain in business.

This is a myth that i have been aware is false for some time.  When we met,  wife worked in the insurance industry and I have had a direct exposure to what it does and why.

Myth 2: Business create jobs

This is one honestly caught me off guard.  It seems reasonable, right?  Business employee people, so they must create jobs.  So give them more money and they will hire more people.

But its also nonsense, or at least incomplete.  Business, as we said above, are in business to make money.  Hiring someone costs money.  The only time  business hires anyone is when they can make more money from that person's work then they cost to hire.  So when is that true?

It is true when there is more demand for a product then they can satisfy with their current work-force.  It is demand that creates the job, and demand is created not by concentrating money in the hands of business but by getting it into the hands of consumers.

Furthermore, a business will not hire more people just because they make more money on each employee (ie through paying less taxes or other incentives.)  It doesn't matter if they make 20% profit on that person or 40% profit on that person. If they can make ANY profit on that person they will hire them.  if not, they won't.

A good rule of thumb is that any time you hear two people say the same thing with the same language, it probably means they are just repeating the words, not thinking deeply about their truth.

Which is to say, they are repeating a myth.

Levels, Story and multi-player roleplay

I'm a believer that common wisdom is generally the most suspect as it gets analyzed the least.   Two design main-stays that have gotten cemented into stone in the MMORPG world are leveling and linear questing.  I'd like to take some time to unpack and examine these as, while both serve important game-play functions, they also both serve as social play barriers.

This is a big topic and can be viewed from many angles.  I'm going to start with my off the cuff take that may be incorrect or incomplete.  (Likely incomplete.)

Leveling was  inherited from the pen and paper RPG space, most notably D&D where it served to shape the character's story into a traditional farm-boy becomes hero arc.  Online it provides goals and a feeling of accomplishment and 'direction' to one's play.  It also 'hooks' the player a tangible recognition and reminder of the time they have a;ready invested in the game and that they would lose if they walked away.  Finally, it gates access to what is generally limited content and doles it out over-time, prolonging the game experience.

Story gives context and meaning to the actions in game, this helps immersion-- particularly with the maybe less imaginative mass market.  It also helps limited and repetitive gameplay to feel more differentiated.  Lastly, it again provides a feeling of motion and progress through the game.  It is linear because, frankly, no human being has really figured out how to tell a non-linear story.  Given that our first instincts as a child telling a story is to begin every sentence with "and then..."  this may be built into us as animals.

All that said, there are real issues and bad second order effects of both of these.  The biggest issues that interest me are how they get in the way of players role-playing together, and what cna be done about that.

Levels, by their gating nature, serve to exclude players from playing with others who do not have characters of similar level.

In our pen and paper games, we could get around this with "tag-along" characters who would level up to the party level pretty fast due to the exponential nature of the experience and reward system.  Some MMORPGs have tried similar things, most notably "City of Heroes" with the Sidekick system.   The problem with that is that, in an MMORPG, this defeats the gating purpose of levels by accelerating the leveling speed of such sidekicks.

Another approach is to "gimp" the higher level character down to the sidekick's level of ability (what players called the "reverse sidekick" in CoH). This is harder to get right.  Go too far and the player feels cheated out of their accomplishments and wont want to do it. Don't go far enough and again they over-balance the content and unreasonably accelerate the advancement of the lower-level character.  It is also difficult to justify from a story/roleplay perspective in two ways; first, why is the higher level character suddenly weaker?  Secondly, it generally means repeating linear content which removes an surprise and breaks the linear flow of the story.

Moving on to linear story, its purpose in part is to help immerse the player.  But it can often end up doing the opposite.  If you allow players to play the same stories over again, then the illusion of linearity totally breaks down.  if you don't, however, then only those characters at the exact same story points can play together.

A second problem with linear story telling is that it doesn't really scale.  Having just defeated Foozle the mighty wizard is a lot less interesting when half the people you run into already defeated him and the other half will be defeating him sometime in the near future.  This effect cheapens the feeling of success, and fights immersion by exposing its artificial nature and the "man behind the curtain."  Ultimately this fights with one of the reasons for having story to begin with.

The most extreme example of this is probably Star Wars:The Old Republic.  This game only makes logical story sense if played with a mixed class set of characters at the exact same place in their stories.  There is a limit  of four players total in such a group because thats the total number of available classes and "your" story is fixed to your class.

That these mechanisms are deep in the core of MMORPG design today is pretty much unarguable.  Funcom's new MMORPG The Secret World claims to be "level-less" on the surface, but if you look a bit deeper its still there.  Its just takes the form of  skill trees and gear acquisition.  The effect is the same however, to gate what content you can or cannot handle.

I would argue that, as barriers to multi-player roleplay, these two assumed game structures have kept us back.  I'd even go farther and say they have made all MMORPGs today to a large degree design failures as Roleplay Games.  The result is that asynchronous play, often called "alone together" play has become the norm.  Doing anything multi-player takes a huge effort on the part of the player so many if not most, don't go to that level but just solo quest and chat with their friends while they do so.  The tactical players will form large teams, but they have no interest in story or roleplay.

If our games are really just tactical games, then we are wasting a lot of effort and resources on roleplay-like features.  If our games are really asynchronous roleplay games then again, we are wasting a huge amount of resources on enabling multi-player gameplay when really all that is needed on the backend is a chat server,  If they  are really supposed to be true multi-player immersive experiences, I'd argue that we are defeating ourselves in relying on these game mechanisms that fight that purpose.

Do you agree?  And if so, what might we do better/instead?  if not, why not?

There is nothing lean about entertainment

Much of the talk as of late in development circles has been about so called "lean-development." The fundamental idea being that you get something out there with the most minimal effort, and if ti flops you drop it and look for something else to do.

This has been fueled by two other marked changes in the game development landscape.  The first was the birth of a new segment, so called "casual" or "social" gaming, with Facebook as its primary platform of delivery. The second has been the related phenomenon of the constantly-connected player and the statistical analysis of player behavior that enables.  These two phenomenon created a "sweet" spot for a lean approach to games.

Any really new platform starts out with very low consumer expectations.  If you haven't looked at an Atari2660 game in years, find an emulator and play one.  Then remember that this was where game consoles began.  Low expectations means you can get away with shipping a minimal product.  Statistical tracking of user behavior is the perfect way to objectively measure the results and find your success or failure.  Together, they were a fertile field for so called lean development.

The problem, however, is game markets grow up.  With each generation of product the users expect more.  The acceptance of lean casual products was mostly a fluke of timing, as opposed to a model that we can follow into the future.  

How well would the movie "inception" tested, I wonder, if it was first presented to viewers as an animatic?  Entertainment is about experience, and you need the whole experience to truly judge any part of it.

As a final example, I'd like to remind the reader of something.  One of the most anticipated movies due for release this summer is "Prometheus", a pre-quel to the movie Alien.  Another hotly talked about movie in pre-production right now is a Blade Runner sequel.

Alien was a flop on initial release.  So was Blade Runner.  They both took time and word of mouth to find their audience.  If the lean model had been followed, these are two movies we probably would never have even seen completed.

With its focus on ship early/cancel early the lean model fits a mature market poorly and can result in our missing very important products and trends.  It is not a brave model, and creating truly new entertainment is a field that rewards bravery.  It can be brave to try something new, but it is more brave to stick to it even when there are doubts as to its eventual success.  I heard a fellow from Rock Star games speak not long ago.  He said that a secret to their success is that they do no focus tests, no marketing surveys, no user play-testing.  Instead, they commit to a vision and work until they see that vision realized.

They have made great and very successful games... and they do it as un-lean as it gets.

Why OO programmers need to understand structured code

Its a natural tendency of people to want to imagine that what they do is somehow revolutionary and breaks with all that came before.  It makes them feel important and justifies laziness in learning history.  But nothing occurs in a vacuum and those who do not study history DO repeat it.

There are many places I take people to task for this today, but the focus of this blog is on object oriented coding and how, far from being revolutionary, it descends in a direct evolutionary path from structured code.  (Note that i am talking about code design and architecture, not so called "Object Oriented Design' which is actually a fad development methodology.  I'll leave that for another rant.)

There are two fundamentals of structured coding that define it. The first is the data structure. A data structure is defined as an organization of data in memory and a set of procedures to act upon it.

The second tenant is top-down design/bottom-up implementation. You start with what your code needs to accomplish and design the data-structure for it. This data structure will then require further data structures beneath it to implement so you design those, and so forth til you get to the bottom most level. The creates a clean multi-layered encapsulated design. You then "bottom up implement", starting with the most primitive data structures in your design and work your way up, testing each structure as it is built.

The first "high level" languages had no direct support for the concept of data structures, so we built them ourselves. In C code this generally meant a .h file to define the public interface and then one or more structs and procedures in a matching .c file. (We did similar things in Pascal.) The limit to only using a data structure's intended public API was a convention that good coder knew to follow but was not enforced by the language.

In response to this came the modular languages-- most notably Modula2. Modula2 added two very important ideas. The first was that it added import/export control. The .h file was replaced by the interface file. The interface file defined the publicly visible API to a code "module", which was just a data structure with some syntactic sugar. Other modules could only see what was published through that interface file. In addition, a module could control what other modules it saw with an import command. (In C and Pascal, all code was globally linked and saw all other global symbols in other files.)

The other important thing Modula2 brought was the concept of an opaque type. This was a publicly usable struct but its definition was hidden inside a module. To the rest of the code it was simply a reference to an instance of a data structure. As you can see, Modual2 was really the half-step between the procedural languages and OOP languages.

OOP languages came next and, just as Modula2 built on simple structured languages, OOP built on the modular languages. Modules became "classes" and the opaque type was formalized into the idea of class instances. More syntactic sugar was added to make such classes easier to define and use, and the level of control of imports was increased.

Fundamentally, however, all an object is is a formalization of a data structure. And good OOP code still has to follow the rules of good data structure design and use. Which, unfortunately, are not getting taught as much as they used to.

Welcome to the Casino

Its time for another rant... and this time it is on the shambles of our national economy.

The legalization of Casinos all over america is an apt metaphor for what our entire economy has become. Investment has grown passé, replaced by speculation. Which is to say, hard work and dedication to a goal are no longer fashionable, instead gambles and throws of the dice to "hit it big" are all the rage.

This has been true of our national investment structure the stock market, for quite awhile. When it was originally constructed, the idea was to let the common people own a piece of a business and share in the profits of that business. Today, a company that generates steady profits is a public failure, growth is all important because the goal of the investor is for their shares to be worth more then when they bought them so they can re-sell them.

This is speculation, which is another word for gambling. Its is also what creates economic bubbles as everyone tries to buy and resell higher, and the last suckers holding the goods take a huge loss to pay for everyone else's profits.

Its not just the market though, we can see this kind of bubble/gambling mentality infecting every part of our economy. When I started in high-tech start-ups 20 years ago, it was about building exciting new products and creating new opportunities. We were creating the world we wanted to live in. We poured our heats and souls into those companies and their products. We *invested* ourselves.

With the $1B buy out of a 24 month old company with one, nascent product by Facebook, that world is totally and thoroughly over. The buzz on the street is all about "quick hits", jump in, release a half-assed product as fast as you can and, if it doesn't hit it huge, dump it and try again.

This is rolling the dice, gambling rather then investing.

Even the business models are slanted towards this, now. The "Free to Play' market is all about a few huge winners and lots of losers. Nowhere in the space is there room for a lovingly crafted niche product. It used to be, a game that sold 5,000 copies could be considered a moderate success. An F2P game with 5,000 users is a dismal failure.

Gambling moves money between pockets, but creates no new lasting value. Its a false value based on others' losses either now or in the future. Thats why bubbles burst. Investing on the other hand builds value, which is why Warren Buffet's shares have never 'burst'.

Investing takes time, and commitment. Where is investment happening today? In the "emerging economies". China, as an example, has been doing a remarkable job of investing in their economic future.

Firefly was probably right. The future language of trade, is probably Chinese.

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.