博客园_马宁的嵌入式开发研究

在Windows Phone应用中添加OpenXLive数据分析功能

2011-10-03T09:36:00Z

作者：马宁

源代码下载地址：

http://files.cnblogs.com/aawolf/OpenXLiveAnalytics.zip

在Windows Phone中很多应用需要数据查询功能，来确定每天的用户数和应用使用次数等关键信息。在iOS和Android中已经有非常多的类似应用了，比如Flurry, 友盟等，但是Windows Phone上只有Flurry提供了此类功能。但由于很多开发者来说，没有中文支持的Flurry有些可望而不可即。

其实，在OpenXLive也提供数据分析的支持，只是之前更多是用于游戏数据的统计和查询上。在这篇文章里，我们将介绍，如何将OpenXLive的数据分析功能应用在Windows Phone的应用程序开发中。

创建OpenXLive应用

因为所有的统计数据都是保存在OpenXLive的云端存储服务器中，所以，我们要在OpenXLive网站上创建一个应用。

首先，登录OpenXLive网站(http://www.openxlive.com/)，如果没有帐号，我们需要创建一个相应的帐号，通过电子邮件激活帐号之后，我们还需要升级成为开发者。

在激活邮件地址后，我们重新回到OpenXLive的网站，输入用户名和密码后，我们会进入用户资料编辑界面，在这里，我们可以填写完整的个人信息，使得朋友在网络中更加容易地找到你。用户资料中最后一项为“Developer Information”。

点击“Developer Information”，进入开发者申请界面：

在这个页面，我们要填写开发者类型（个人/公司/学生）、国家、城市、地址、电话、IM等信息。在填写完成后，我们会看到下面的开发者注册成功界面。

在这个界面中，我们可以进入OpenXLive开发者首页，查看开发指南，也可以直接点击“Create New Game”，进入开发者后台。

进入开发者后台界面之后，如果您之前已经创建过游戏，会显示已创建游戏的列表，如上图所示。在用户图标的下方，有Create New Game的按钮，点击，进入创建新游戏的界面。

添加OpenXLive引用

为了引用OpenXLive的程序集，我们必须首先下载OpenXLive SDK并且完成安装。下载地址是：http://developer.openxlive.com/sdk/download/ 目前的版本是0.9.6.

创建Windows Phone Silverlight应用后，我们要获取OpenXLive的程序集。在开始菜单中，找到OpenXLive应用，其中OpenXLive目录下包括XNA和Silverlight两个目录。我们从Silverlight目录中取出OpenXLive.dll程序集，拷贝至我们的应用所在的目录。

然后在Solution Explorer中，右键单击References，选择Add Reference。在对话框中选择Browse页面，然后找到OpenXLive.dll，将其添加到工程中。

因为我们不需要OpenXLive的界面，所以只需要添加OpenXLive.dll即可。

在添加完引用之后，我们就可以添加代码了。

创建Session

接下来，我们要为工程添加OpenXLive的引用代码。打开工程中的App.xaml.cs文件，首先找到Application_Launching方法：

private void Application_Launching(object sender, LaunchingEventArgs e)
{
    if (XLiveGameManager.CurrentSession == null)
    {
        GameSession session = XLiveGameManager.CreateSession("xxxxxxxx");
        session.CreateSessionCompleted += new AsyncEventHandler(session_CreateSessionCompleted);
        session.Open();
    }
}

我们在这个方法里判断是否已经有Game Session存在，如果没有的话，则调用XLiveGameManager的CreateSession方法来创建一个Game Session，需要传递的参数，是我们在OpenXLive网站上获得的Secret Key。

然后，我们可以添加一个CreateSessionCompleted事件处理函数，来获取Game Session是否被创建的事件。当然，这个事件处理函数是可选的，我们可以不添加。

最后，调用Game Session的Open方法，来打开Game Session就可以了。

然后是关闭这个Game Session，在Application_Closing方法里调用Close方法。

private void Application_Closing(object sender, ClosingEventArgs e)
{
    if (XLiveGameManager.CurrentSession != null)
    {
        XLiveGameManager.CurrentSession.Close();
    }
}

如果我们不显式调用Close方法的话，Game Session在创建24小时后会自动过期，所以也不会造成太大的影响，唯一的问题是游戏时间将失效。

为了支持墓碑机制，我们还要特意在Application_Activated和Application_Deactivated函数中，添加对于墓碑机制的处理。

private void Application_Activated(object sender, ActivatedEventArgs e)
{
    XLiveGameManager.Activated();
}

private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
    XLiveGameManager.Deactivated();
}

好了，到这里我们就大功告成了，够简单吧？

查看数据结果

当我们的Windows Phone软件发布之后，就可以在OpenXLive网站上查看应用程序的在线数据了。

首先，我们访问OpenXLive网站http://www.openxlive.com/ ，在网页右上角点击Login登录，成功登录之后，我们会在OpenXLive首页右上角的位置看到下面的网页：

点击My Game，可以进入游戏后台管理的Dashboard中。如果用户登录后，访问OpenXLive开发者网站(http://developer.openxlive.com/)，在右侧的Dashboard中选择“Managed your games”也可以进入开发者后台管理界面。

上图所示，包括我们创建的所有游戏和应用，点击应用图标会进入应用的产业页面，点击应用标题，则进入应用的管理界面。

点击管理界面中的Statistics按钮，进入数据分析界面。

在数据分析界面中，我们可以查看一些通用信息，比如创建Session的数量、使用人数等信息。点击View，则进入详细数据分析界面。

在详细数据分析界面中，我们可以考到用户数、Session数的时间分布，按照月、周、日来进行显示等。

写在最后

好了，到这里，我们就介绍完OpenXLive目前的数据分析功能。下一步，OpenXLive还会加入自定义事件、地理分布信息等功能。

本文链接

Kinect for Windows SDK开发初体验（四）景深数据

2011-08-25T14:26:00Z

作者：马宁

终于可以坐下来继续这个系列了，在微博和博客园里，已经有无数人催过了，实在抱歉，一个人的精力毕竟是有限的，但我会抽出一切可用的时间，尽可能尽快完成。

这一章我们来说说景深数据Depth Data，这是Kinect的Depth Camera为我们提供的全新功能，以往的技术只能够通过图像识别来完成的一些工作，我们可以借助景深来帮我们完成了。比如，前景与背景的分离，以前只能将背景设置为蓝屏或者绿屏，但是现在有了景深数据，我们就可以很容易地将前景物体从背景中分离出来。当然，需要特别说明的是，Depth Camera技术是由以色列公司PrimeSense提供的。

程序布局

在这一章里，我们要完成的工作非常简单，根据物体距离Kinect的远近，设置成不同的颜色。首先，我们要创建一个新的WPF工程，然后添加一个Image控件：

<Image Height="240" HorizontalAlignment="Left" Margin="62,41,0,0" Name="image1" Stretch="Fill" VerticalAlignment="Top" Width="320" />

然后是MainWindow.xaml.cs中的核心代码，这部分代码与之前的代码大体一致，所以不做过多解释了：

//Kinect RuntimeRuntime 

Runtime nui = new Runtime(); 

private void Window_Loaded(object sender, RoutedEventArgs e)

{

//UseDepthAndPlayerIndex and UseSkeletalTracking

nui.Initialize(RuntimeOptions.UseDepthAndPlayerIndex | RuntimeOptions.UseSkeletalTracking);

//register for event

nui.DepthFrameReady += new EventHandler<ImageFrameReadyEventArgs>(nui_DepthFrameReady);

//DepthAndPlayerIndex ImageType

nui.DepthStream.Open(ImageStreamType.Depth, 2, ImageResolution.Resolution320x240,

ImageType.DepthAndPlayerIndex);

}

private void Window_Closed(object sender, EventArgs e)

{

nui.Uninitialize();

}

唯一需要大家注意的是，我们在初始化函数中传递的参数是RuntimeOptions.UseDepthAndPlayerIndex，这表示景深信息中会包含PlayerIndex的信息。接下来，我们就要花点时间来理解DepthAndPlayerIndex的实际结构。

理解DepthAndPlayerIndex

先来看DepthFrameReady事件处理函数，如下：

void nui_DepthFrameReady(object sender, ImageFrameReadyEventArgs e)

{

// Convert depth information for a pixel into color information 

byte[] ColoredBytes = GenerateColoredBytes(e.ImageFrame); 

// create an image based on the colored bytes 

PlanarImage image = e.ImageFrame.Image;

image1.Source = BitmapSource.Create( 

image.Width, image.Height, 96, 96, PixelFormats.Bgr32, 

null, ColoredBytes, image.Width * PixelFormats.Bgr32.BitsPerPixel / 8); 

}

DepthFrameReady事件会返回一个ImageFrame对象，其中会包含一个PlanarImage对象。PlanarImage对象会包含一个byte[]数组，这个数组中包含每个像素的深度信息。这个数组的特点是，从图像左上角开始、从左到右，然后从上到下。

该数组中每个像素由两个bytes表示，我们需要通过位运算的办法来获取每个像素的位置信息。

如果是Depth Image Type，将第二个bytes左移8位即可。

Distance (0,0) = (int)(Bits[0] | Bits[1] << 8 );

如果是DepthAndPlayerIndex Image Type，第一个bytes右移三位去掉Player Index信息，第二个bytes左移5位。

Distance (0,0) =(int)(Bits[0] >> 3 | Bits[1] << 5);

DepthAndPlayerIndex image类型的第一个bytes前三位包括Player Index信息。Player Index最多包含六个可能值：

0，没有玩家；1，玩家1；2，玩家2，以此类推。

我们可以用下面的方法来获取Player Index信息：

private static int GetPlayerIndex(byte firstFrame)

{

//returns 0 = no player, 1 = 1st player, 2 = 2nd player...

return (int)firstFrame & 7; 

}

设置颜色

接下来，我们创建一个bytes数组，用来存储颜色值。

if (distance <= 900)

{

//we are very close

colorFrame[index + BlueIndex] = 255;

colorFrame[index + GreenIndex] = 0;

colorFrame[index + RedIndex] = 0;

}

if (GetPlayerIndex(depthData[depthIndex]) > 0)

{

//we are the farthest

colorFrame[index + BlueIndex] = 0;

colorFrame[index + GreenIndex] = 255;

colorFrame[index + RedIndex] = 255;

}

当然，我们最好是设置几个边界值，来定义不同距离的不同颜色：

//equal coloring for monochromatic histogram

var intensity = CalculateIntensityFromDepth(distance);

colorFrame[index + BlueIndex] = intensity;

colorFrame[index + GreenIndex] = intensity;

colorFrame[index + RedIndex] = intensity;

const float MaxDepthDistance = 4000; // max value returned

const float MinDepthDistance = 850; // min value returned

const float MaxDepthDistanceOffset = MaxDepthDistance - MinDepthDistance;

public static byte CalculateIntensityFromDepth(int distance)

{

//formula for calculating monochrome intensity for histogram

return (byte)(255 - (255 * Math.Max(distance - MinDepthDistance, 0) / (MaxDepthDistanceOffset)));

}

最后，把所有代码放在一起，我们设定的颜色值为：

蓝色，小于900；900到2000，绿色；大于2000，红色

代码如下：

private byte[] GenerateColoredBytes(ImageFrame imageFrame)
        {    
            int height = imageFrame.Image.Height;    
            int width = imageFrame.Image.Width;     
            
            //Depth data for each pixel    
            Byte[] depthData = imageFrame.Image.Bits;      
            
            //colorFrame contains color information for all pixels in image    
            //Height x Width x 4 (Red, Green, Blue, empty byte)    
            Byte[] colorFrame = new byte[imageFrame.Image.Height * imageFrame.Image.Width * 4];     
            
            //Bgr32  - Blue, Green, Red, empty byte    
            //Bgra32 - Blue, Green, Red, transparency     
            //You must set transparency for Bgra as .NET defaults a byte to 0 = fully transparent     
            //hardcoded locations to Blue, Green, Red (BGR) index positions           
            const int BlueIndex = 0;    
            const int GreenIndex = 1;    
            const int RedIndex = 2;     
            var depthIndex = 0;    
            
            for (var y = 0; y < height; y++)    
            {                
                var heightOffset = y * width;         
                
                for (var x = 0; x < width; x++)        
                {            
                    var index = ((width - x - 1) + heightOffset) * 4;             
                    
                    //var distance = GetDistance(depthData[depthIndex], depthData[depthIndex + 1]);            
                    var distance = GetDistanceWithPlayerIndex(depthData[depthIndex], depthData[depthIndex + 1]);             
                    
                    if (distance <= 900)            
                    {                
                        //we are very close                
                        colorFrame[index + BlueIndex] = 255;                
                        colorFrame[index + GreenIndex] = 0;                
                        colorFrame[index + RedIndex] = 0;                   
                    }            
                    else if (distance > 900 && distance < 2000)            
                    {                
                        //we are a bit further away                
                        colorFrame[index + BlueIndex] = 0;                
                        colorFrame[index + GreenIndex] = 255;                
                        colorFrame[index + RedIndex] = 0;            
                    }            
                    else if (distance > 2000)            
                    {                
                        //we are the farthest                
                        colorFrame[index + BlueIndex] = 0;                
                        colorFrame[index + GreenIndex] = 0;                
                        colorFrame[index + RedIndex] = 255;            
                    }             
                    
                    //Color a player            
                    if (GetPlayerIndex(depthData[depthIndex]) > 0)            
                    {                
                        //we are the farthest                
                        colorFrame[index + BlueIndex] = 0;                
                        colorFrame[index + GreenIndex] = 255;                
                        colorFrame[index + RedIndex] = 255;            
                    }             
                    
                    //jump two bytes at a time            
                    depthIndex += 2;        
                
                }    
            }     
            
            return colorFrame;
        }

程序的现实效果如下图：

写到最后

到这里，我们就将Kinect SDK中NUI的基本内容介绍完了，接下来，我们要介绍Audio部分，或者借助一些实际的例子，来看一下Kinect SDK的实际应用。

本文链接

马宁的Windows Phone 7.1初体验（三）——Tile

2011-08-02T18:36:00Z

作者：马宁

前边介绍Push Notification时，其实已经谈到了Tile Notification。在Windows Phone 7.1中，Smart Tile得到了极大的提高。我们不但可以控制Tile的动画显示、内容和背景切换，而且还能够为同一个应用提供两个Tile，比如一个天气预报的应用程序，就可以在手机的首页上显示多个Tile，一个是北京的天气，另一个是上海的天气等。

实现Application Tile

MSDN上的文章写的又臭又长，其实挺简单的事情，弄得那么复杂。我试着改写了一下例子，加入到应用的一个Button点击事件里：

// Application Tile is always the first Tile, even if it is not pinned to Start.
            ShellTile TileToFind = ShellTile.ActiveTiles.First();

            // Set the properties to update for the Application Tile.
            // Empty strings for the text values and URIs will result in the property being cleared.
            StandardTileData NewTileData = new StandardTileData
            {
                Title = "Title",
                BackgroundImage = new Uri("Background.png", UriKind.Relative),
                Count = 2,
                BackTitle = "Back Tilte",
                BackBackgroundImage = new Uri("Background2.png", UriKind.Relative),
                BackContent = "This is BackContent"
            };

            // Update the Application Tile
            TileToFind.Update(NewTileData);

首先，我们要引用Microsoft.Phone.Shell命名空间，然后通过ShellTile.ActiveTiles.First()方法来获取应用最主要的ShellTile.每个应用至少会有一个Tile，所以不用担心该对象为空。然后我们创建一个StandardTileData对象，为其中的属性赋值。属性分为两组，每组都会有背景图片、标题和内容，显示位置如下图所示。如果设置两组Tile属性，则Tile在显示一段时间后会自动切换。最后，我们调用ShellTile对象的Update方法，将StandardTileData对象传递进去，就完成了新Tile的设置。BackgroundImage和BackBackgroundImage指定的是图片的URI，可以是本地的图片，也可以是来自网络的图片。我们使用的两个图片，都是以Content方式加入到工程中的图片。

当我们将程序部署到设备或模拟器上时，首先会在Application List里出现对应的图标。我们长按图标，会出现一个菜单，选择Pin to start，会将应用程序的图标显示到手机首页上。

运行应用程序，点击Button后，Tile会被更新成新的式样。两张背景和内容会交替显示，显示效果如下图所示：

实现 Secondary Tile

在完成了Application Tile的显示之后，我们接下来要实现更复杂的Secondary Tile，当然，我们可以添加多个Tile。在实现Secondary Tile时，有两个技术点需要实现，一个是Tile的添加与显示；另一个则是，程序启动时如何区分是由哪个Tile点击启动应用的。

首先，我们来看如何添加Secondary Tile的代码：

// Look to see whether the Tile already exists and if so, don't try to create it again.
            ShellTile TileToFind = ShellTile.ActiveTiles.FirstOrDefault(x => x.NavigationUri.ToString().Contains("DefaultTitle=FromTile"));

            // Create the Tile if we didn't find that it already exists.
            if (TileToFind == null)
            {
                // Create the Tile object and set some initial properties for the Tile.
                // The Count value of 12 shows the number 12 on the front of the Tile. Valid values are 1-99.
                // A Count value of 0 indicates that the Count should not be displayed.
                StandardTileData NewTileData = new StandardTileData
                {
                    BackgroundImage = new Uri("Background.png", UriKind.Relative),
                    Title = "Secondary Tile",
                    Count = 12,
                    BackTitle = "Back of Tile",
                    BackContent = "Welcome to the back of the Tile",
                    BackBackgroundImage = new Uri("Background2.png", UriKind.Relative)
                };

                // Create the Tile and pin it to Start. This will cause a navigation to Start and a deactivation of our application.
                ShellTile.Create(new Uri("/MainPage.xaml?DefaultTitle=FromTile", UriKind.Relative), NewTileData);
            }
            else
            {
                TileToFind.Delete();
            }

首先调用ShellTile.ActiveTiles.FirstOrDefault方法，获取在NavigationUri属性中包含“DefaultTitle=FromTile”字样的ShellTile对象，如果获取到的ShellTile对象为空，则创建Secondary Tile，否则调用ShellTile的Delete方法，删除这个Tile。

创建Secondary Tile的过程，首先创建StandardTileData对象，将显示的各个参数进行赋值，这一步与Application Tile相同；然后，调用ShellTile的Create方法，第一个参数是URI，即点击该Tile后，调用Page的命令行，可以包含参数，第二个参数是StandardTileData对象，用于指定显示式样。

需要注意的是，如果Page命令行指定不对，会引起用户点击Tile时，应用直接退出，由于无法调试，第一次接触这个问题时，会找不到具体的原因。

Secondary Tile显示效果如下：

接下来，我们就要处理区分不同Tile点击的事件了，需要重载MainForm的OnNavigatedTo方法：

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
        {
            string value = null;

            if (this.NavigationContext.QueryString != null)
            {
                this.NavigationContext.QueryString.TryGetValue("DefaultTitle", out value);
                if (value != null)
                {
                    textBoxTitle.Text = value;
                }
                else
                {
                    textBoxTitle.Text = "FromMain";
                }
            }

            base.OnNavigatedTo(e);
        }

通过NavigationContext.QueryString的TryGetValue方法来获取DefaultTitle参数的值，如果无法获取到该值，则认为该点击来自第一个Tile，相反则来自第二个Tile。我们将参数显示在主页面的文本框里，当然，实际应用中可以有更加复杂的业务逻辑。界面显示效果如下：

到这里，我们简单介绍了如何添加Tile、修改Tile内容，除此之外，还有如何修改Tile的初始值，指定Tile更新的时间间隔等。在这里，我们就不介绍了，大家可以参考又臭又长的MSDN文档，这部分不长，我可以保证。

写在最后

好了，到这里，我们正式将Windows Phone 7.1中的Tile编程的内容介绍完了。Windows Phone采用的是HUB方式，对于功能进行分类，所以，就要求Tile具备更丰富的显示方式和展现形式。而且，多个应用可以对应于一个Tile，同样一个应用也可以对应多个Tile，这样极大提高了主页与应用之间交互的丰富程度。

当然，具体的Tile，还要在实际的开发中使用，才能真正了解其优缺点。

OpenXLive杯Windows Phone游戏开发大赛

OpenXLive杯Windows Phone游戏开发大赛，是由OpenXLive联合国内知名的开发者社区：DevDiv、智机网、WPMind、Silverlight银光中国和XNA游戏世界，一起举办的针对Windows Phone游戏开发的比赛。

http://www.openxlive.net/posts/news/40

本文链接

马宁的Windows Phone 7.1初体验（二）——Push Notification

2011-08-01T17:24:00Z

作者：马宁

Push Notification并不是Windows Phone 7.1的新功能，但是之前的文章里对这部分都缺少详细的分析，所以姑且就把Push Notification放到这部分里吧。

很多iOS开发者都将WP7里的Push Notification说成抄袭iOS的产物，孰不知，微软才是Push Notification技术的先行者，Windows Mobile时代的Push Mail技术可以说是独步天下，连Symbian也要授权使用相关的技术。

Push Notification的技术为什么越来越重要，其实这跟移动设备的特点紧密相关，移动设备网络的不稳定性，决定了以Socket为代表的强连接方式并不适用，所以大家更多选择HTTP协议作为主要的通讯方式。但是HTTP的特点是，设备找服务器很容易，通过URL就可以了，但服务器找设备就难上加难了，因为设备会随时切换移动网络，IP地址之类的经常性失效。当然设备端轮询的方式可以解决这个问题，但移动设备的电源、网络都是稀缺资源。所以，OS级别的Push Notification技术就变成了一种珍贵的战略资源，而且，在封闭式的操作系统中，只有OS厂商提供的Push Notification才能够获得最好的效率。

Push Notification简介

目前，Windows Phone支持三种Push Notification方式：Toast Notifications、Tile Notifications和Raw Notifications，我不想翻译成中文名字了，因为“吐司”之类的翻译无法帮助理解。

Toast Notifications，当我们的程序没有运行时，我们希望有一种形式可以通知用户，并且让用户调用对应的应用，就像收到SMS时，调用Messaging程序一样。运行效果如下图，当用户点击Toast时，可以调用对应的程序。

Tile Notifications，用于更新启动界面上的Tile，可以通过Tile Notifications设置Tile的背景图片、Count和Title等属性，各属性显示位置如下图所示。我们可以通过该技术来提示用户，我们的应用有新的事件发生，比如SNS上有多少新的回复等。

Raw Notifications，最简单，当你的应用程序运行时，可以接收Raw Notification信息，如果程序没有运行，则接受不到Raw Notification。

接下来，我们会以Toast Notifications为例详细介绍，Push Notification的原理和使用方法。

首先，还是引用这张广为流传的图示吧，确实是目前能够找到的最详细的示意图了。下面是步骤叙述：

1-3，应用通过调用HttpNotificationChannel接口，向Microsoft Push Notification Service (MPNS)请求一个URI，这个URI会在服务器端发送Notification消息时，作为验证发送目标的唯一标识；这样做的一个好处是，当同一个设备上有多个应用在监听Notification时，不会相互干扰。

4. 应用会将获得的URI传到自己的服务器上，这个URI会存储在自己的服务器上，用于发送Push Notification时调用。URI的传递和存储方式，由开发者自己决定，不过要保证传输过程的加密，以及存储时的安全性。接下来的实例里，传递和存储URI的方式就很有创意。

5-6. 当服务器端有信息要通知应用时，需要向MPNS发起一个Http请求，而MPNS将请求转发到相应的设备上，设备上的应用接到Push Notification的消息后，进行相应的处理。

其实过程挺简单，被MSDN文档说得神乎其神。接下来，我们挨个看一下各个类型的Notification。偷点懒，不自己写Sample Code了，请大家去下面的链接里下载。不过注意Sample Code的更新，最近有同学因为更新不及时，而影响了开发进度。

http://msdn.microsoft.com/en-us/library/ff431744(VS.92).aspx

初始化 Notifications

首先是Toast Notifications，这种Notification在实际应用中最为有效，不但可以提示用户有新的消息，而且还让用户选择是否打开当时的应用。不过比起iOS的Notifications来，Toast Notifications能够容纳的信息量实在有限。所以，开发者要适当“浓缩”需要推送的消息。

我们按照调用的顺序，依次来分析代码，首先来看客户端部分ToastNotificationClient的代码：

/// Holds the push channel that is created or found.
            HttpNotificationChannel pushChannel;

            // The name of our push channel.
            string channelName = "ToastSampleChannel";

            InitializeComponent();

            // Try to find the push channel.
            pushChannel = HttpNotificationChannel.Find(channelName);

            // If the channel was not found, then create a new connection to the push service.
            if (pushChannel == null)
            {
                pushChannel = new HttpNotificationChannel(channelName);

                // Register for all the events before attempting to open the channel.
                pushChannel.ChannelUriUpdated += new EventHandler<NotificationChannelUriEventArgs>(PushChannel_ChannelUriUpdated);
                pushChannel.ErrorOccurred += new EventHandler<NotificationChannelErrorEventArgs>(PushChannel_ErrorOccurred);

                // Register for this notification only if you need to receive the notifications while your application is running.
                pushChannel.ShellToastNotificationReceived += new EventHandler<NotificationEventArgs>(PushChannel_ShellToastNotificationReceived);

                pushChannel.Open();

                // Bind this new channel for toast events.
                pushChannel.BindToShellToast();

            }
            else
            {
                // The channel was already open, so just register for all the events.
                pushChannel.ChannelUriUpdated += new EventHandler<NotificationChannelUriEventArgs>(PushChannel_ChannelUriUpdated);
                pushChannel.ErrorOccurred += new EventHandler<NotificationChannelErrorEventArgs>(PushChannel_ErrorOccurred);

                // Register for this notification only if you need to receive the notifications while your application is running.
                pushChannel.ShellToastNotificationReceived += new EventHandler<NotificationEventArgs>(PushChannel_ShellToastNotificationReceived);

                // Display the URI for testing purposes. Normally, the URI would be passed back to your web service at this point.
                System.Diagnostics.Debug.WriteLine(pushChannel.ChannelUri.ToString());
                MessageBox.Show(String.Format("Channel Uri is {0}",
                    pushChannel.ChannelUri.ToString()));

            }

代码比较多，我们逐步来看，首先要声明一个HttpNotificationChannel的变量，命名空间为Microsoft.Phone.Notification。接下来，声明该Notification Channel的名称，该名称是Channel的唯一标识名，不能与其他Channel重复。接下来，我们调用HttpNotificationChannel的静态方法Find来查找，当前的Channel是否存在，如果存在则返回HttpNotificationChannel对象实例，不存在则返回空。如果该程序从未在当前设备上运行过，则HttpNotificationChannel对象为空，只要运行过一次，则能够通过Find方法来获取对象实例。

先来说未创建Channel的情况，创建HttpNotificationChannel的对象，并将Channel名称作为参数传递进去。然后处理该对象的两个事件：ChannelUriUpdated和ErrorOccurred。当URI发生变化时，会触发ChannelUriUpdated事件，我们在创建Channel对象时，会触发该事件，另外一个ErrorOccurred事件，则用于错误处理。

当程序已经在运行时，默认是接收不到Toast Notification消息的，所以，我们还需要处理ShellToastNotificationReceived事件，当程序运行时，也可以接收到相应的消息。

然后调用HttpNotificationChannel的Open方法，打开该Channel，最后是BindToShellToast方法，通知Shell，该Notification的Channel已经被创建。

获取Channel后的代码与之大体类似，但我们可以通过HttpNotificationChannel的ChannelUri属性来获取Channel的URI，该URI值就是需要传递给我们自己服务器的唯一值，标记了该设备上的该Channel。

而创建Channel后，我们也可以获取URI的值，不过我们需要在ChannelUriUpdated事件处理函数里获取该URI值：

void PushChannel_ChannelUriUpdated(object sender, NotificationChannelUriEventArgs e)
        {

            Dispatcher.BeginInvoke(() =>
            {
                // Display the new URI for testing purposes.   Normally, the URI would be passed back to your web service at this point.
                System.Diagnostics.Debug.WriteLine(e.ChannelUri.ToString());
                MessageBox.Show(String.Format("Channel Uri is {0}",
                    e.ChannelUri.ToString()));

            });
        }

到此为止，我们已经完成了Notification Channel的创建，并且获得了唯一标识的URI。

触发Notification

接下来，我们来看Server的代码。我们自己的Server与Microsoft Push Notification Server（MPNS）之间是通过Http协议，使用HttpWebRequest来发送请求。理论上来说，我们也可以使用客户端程序向MPNS发送Notification请求。为什么要用ASP.NET来编写，最主要的原因还是在于客户端应用要将URI传递给Server端，显然基于ASP.NET的Web应用在这方面是最容易的。

不过我们的实例中，没有客户端将URI传递给服务器端的代码，而是采用了最简单的办法：由开发者直接将URI拷贝到ASP.NET的Web应用中。

接下来，我们来看Server端的代码：

try
            {
                // Get the Uri that the Microsoft Push Notification Service returns to the Push Client when creating a notification channel.
                // Normally, a web service would listen for Uri's coming from the web client and maintain a list of Uri's to send
                // notifications out to.
                string subscriptionUri = TextBoxUri.Text.ToString();


                HttpWebRequest sendNotificationRequest = (HttpWebRequest)WebRequest.Create(subscriptionUri);

                // We will create a HTTPWebRequest that posts the toast notification to the Microsoft Push Notification Service.
                // HTTP POST is the only allowed method to send the notification.
                sendNotificationRequest.Method = "POST";

                // The optional custom header X-MessageID uniquely identifies a notification message. 
                // If it is present, the // same value is returned in the notification response. It must be a string that contains a UUID.
                // sendNotificationRequest.Headers.Add("X-MessageID", "<UUID>");

                // Create the toast message.
                string toastMessage = "<?xml version=\"1.0\" encoding=\"utf-8\"?>" +
                "<wp:Notification xmlns:wp=\"WPNotification\">" +
                   "<wp:Toast>" +
                        "<wp:Text1>" + TextBoxTitle.Text.ToString() + "</wp:Text1>" +
                        "<wp:Text2>" + TextBoxSubTitle.Text.ToString() + "</wp:Text2>" +
                        "<wp:Param>/Page2.xaml?NavigatedFrom=Toast Notification" + TextBoxSubTitle.Text.ToString() + "</wp:Param>" +
                   "</wp:Toast> " +
                "</wp:Notification>";

                // Sets the notification payload to send.
                byte[] notificationMessage = Encoding.Default.GetBytes(toastMessage);

                // Sets the web request content length.
                sendNotificationRequest.ContentLength = notificationMessage.Length;
                sendNotificationRequest.ContentType = "text/xml";
                sendNotificationRequest.Headers.Add("X-WindowsPhone-Target", "toast");
                sendNotificationRequest.Headers.Add("X-NotificationClass", "2");


                using (Stream requestStream = sendNotificationRequest.GetRequestStream())
                {
                    requestStream.Write(notificationMessage, 0, notificationMessage.Length);
                }

                // Send the notification and get the response.
                HttpWebResponse response = (HttpWebResponse)sendNotificationRequest.GetResponse();
                string notificationStatus = response.Headers["X-NotificationStatus"];
                string notificationChannelStatus = response.Headers["X-SubscriptionStatus"];
                string deviceConnectionStatus = response.Headers["X-DeviceConnectionStatus"];

                // Display the response from the Microsoft Push Notification Service.  
                // Normally, error handling code would be here.  In the real world, because data connections are not always available,
                // notifications may need to be throttled back if the device cannot be reached.
                TextBoxResponse.Text = notificationStatus + " | " + deviceConnectionStatus + " | " + notificationChannelStatus;
            }
            catch (Exception ex)
            {
                TextBoxResponse.Text = "Exception caught sending update: " + ex.ToString();
            }

Server端程序的主体是调用HttpWebRequest对象，来实现HTTP POST的方法。发送的消息以XML形式呈现，在上面代码中表现为toastMessage字符串，wp:Toast指定Notification类型，wp:Text1指定标题，wp:Text2指定子标题，wp:Param指定传递的参数。

请大家注意wp:Param，我们可以认为该参数相当于调用了客户端应用中NavigationService的Navigate方法，必须确认客户端有指定的页面可以进行跳转。当用户点击Toast Notification的提示条时，客户端应用会调用wp:Param，从而跳转到指定界面上。

我们可以通过该参数来传递一些参数，比如标识本次Notification是由哪条消息引发的。不过该参数中不应该包括敏感信息、安全信息，因为无法保证这些信息的安全。最好的办法是，传递一个ID值，当客户端访问服务器时，由服务器端判断该ID是否有效。

接下来，我们还要为HTTP 头添加自定义字段，这部分参考Sample Code就可以了。

接收Notification

当Server端代码完成后，我们回到客户端，看一下当MPNS找到设备后，如何触发我们的客户端代码。首先是Page2.xaml的OnNavigatedTo方法：

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
        {
            base.OnNavigatedTo(e);

            //  If we navigated to this page
            // from the MainPage, the DefaultTitle parameter will be "FromMain".  If we navigated here
            // when the secondary Tile was tapped, the parameter will be "FromTile".
            textBlockFrom.Text = "Navigated here from " + this.NavigationContext.QueryString["NavigatedFrom"];
        }

通过NavigationContext.QueryString属性来获取自定义参数，试过传两个参数，后一个收到不到，目前成功的是传递一个参数的情况。

还有一种情况是，当客户端程序运行时，接收到Toast Notification时，该如何处理：

void PushChannel_ShellToastNotificationReceived(object sender, NotificationEventArgs e)
        {
            StringBuilder message = new StringBuilder();
            string relativeUri = string.Empty;

            message.AppendFormat("Received Toast {0}:\n", DateTime.Now.ToShortTimeString());

            // Parse out the information that was part of the message.
            foreach (string key in e.Collection.Keys)
            {
                message.AppendFormat("{0}: {1}\n", key, e.Collection[key]);

                if (string.Compare(
                    key,
                    "wp:Param",
                    System.Globalization.CultureInfo.InvariantCulture,
                    System.Globalization.CompareOptions.IgnoreCase) == 0)
                {
                    relativeUri = e.Collection[key];
                }
            }

            // Display a dialog of all the fields in the toast.
            Dispatcher.BeginInvoke(() => MessageBox.Show(message.ToString()));

        }

该方法是HttpNotificationChannel的ShellToastNotificationReceived事件处理函数，具体内容不详细解释了。

Tile Notifications

Tile Notification是另一种Notification，主要用于在Windows Phone的首页上显示Smart Tile。很多内置的WP应用可以显示Tile上的自定义显示，比如Messaging程序里可以显示当前未读的短信有多少。Tile Notification可以帮助我们实现类似的功能，通常的一个用法是，首先发送一条Toast Notification，如果用户不理睬，可以发送一条Tile Notification，在Smart Tile上显示提示，让用户在方便时，再处理该条请求。

Tile Notification的实现代码与Toast Notification类似，所以，我们不在这里列出全部源代码了，只是列出与上面不同的部分代码。

首先来看Server部分的代码：

// Create the tile message.
                string tileMessage = "<?xml version=\"1.0\" encoding=\"utf-8\"?>" +
                "<wp:Notification xmlns:wp=\"WPNotification\">" +
                    "<wp:Tile>" +
                      "<wp:BackgroundImage>" + TextBoxBackgroundImage.Text + "</wp:BackgroundImage>" +
                      "<wp:Count>" + TextBoxCount.Text + "</wp:Count>" +
                      "<wp:Title>" + TextBoxTitle.Text + "</wp:Title>" +
                      "<wp:BackBackgroundImage>" + TextBoxBackBackgroundImage.Text + "</wp:BackBackgroundImage>" +
                      "<wp:BackTitle>" + TextBoxBackTitle.Text + "</wp:BackTitle>" +
                      "<wp:BackContent>" + TextBoxBackContent.Text + "</wp:BackContent>" +
                   "</wp:Tile> " +
                "</wp:Notification>";

                // Sets the notification payload to send.
                byte[] notificationMessage = Encoding.Default.GetBytes(tileMessage);

                // Sets the web request content length.
                sendNotificationRequest.ContentLength = notificationMessage.Length;
                sendNotificationRequest.ContentType = "text/xml";
                sendNotificationRequest.Headers.Add("X-WindowsPhone-Target", "token");
                sendNotificationRequest.Headers.Add("X-NotificationClass", "1");

TileMessage与ToastMessage大体类似，标签变为wp:Tile，而其中包括的数据分为两组：BackgroundImage、Title和Content，显示位置可以参考文章前面的示意图。BackgroundImage可以是本地的资源，也可以是远程的图片链接。

接下来是客户端的部分代码：

pushChannel = new HttpNotificationChannel(channelName);

                // Register for all the events before attempting to open the channel.
                pushChannel.ChannelUriUpdated += new EventHandler<NotificationChannelUriEventArgs>(PushChannel_ChannelUriUpdated);
                pushChannel.ErrorOccurred += new EventHandler<NotificationChannelErrorEventArgs>(PushChannel_ErrorOccurred);

                pushChannel.Open();

                // Bind this new channel for Tile events.
                pushChannel.BindToShellTile();

Tile Notification无需添加任何额外的代码，在调用HttpNotificationChannel的Open方法后，还需要调用BindToShellTile的方法，通知Shell绑定该Tile Notification。

Raw Notifications

Raw Notification的用法最简单，在程序运行时，收到Raw Notification时，更新应用程序界面上的某些元素。

首先，我们来看Server端的代码：

// Create the raw message.
                string rawMessage = "<?xml version=\"1.0\" encoding=\"utf-8\"?>" +
                "<root>" +
                    "<Value1>" + TextBoxValue1.Text.ToString() + "<Value1>" +
                    "<Value2>" + TextBoxValue2.Text.ToString() + "<Value2>" +
                "</root>";

                // Sets the notification payload to send.
                byte[] notificationMessage = Encoding.Default.GetBytes(rawMessage);

                // Sets the web request content length.
                sendNotificationRequest.ContentLength = notificationMessage.Length;
                sendNotificationRequest.ContentType = "text/xml";
                sendNotificationRequest.Headers.Add("X-NotificationClass", "3");

RawMessage非常简单，只需要指定Value1, Value2就可以了，这些值是自定义的，然后指定HTTP头的X-NotificationgClass的值为3，代表Raw Notification。

接下来是客户端代码的片段：

pushChannel = new HttpNotificationChannel(channelName);
pushChannel.HttpNotificationReceived += new EventHandler<HttpNotificationEventArgs>(PushChannel_HttpNotificationReceived);
pushChannel.Open();


        void PushChannel_HttpNotificationReceived(object sender, HttpNotificationEventArgs e)
        {
            string message;

            using (System.IO.StreamReader reader = new System.IO.StreamReader(e.Notification.Body))
            {
                message = reader.ReadToEnd();
            }


            Dispatcher.BeginInvoke(() =>
                MessageBox.Show(String.Format("Received Notification {0}:\n{1}",
                    DateTime.Now.ToShortTimeString(), message))
                    );
        }

HttpNotificationChannel创建完成后，只需要调用Open方法即可，不需要绑定到Shell上。另外，还需要处理HttpNotificationChannel的HttpNotificationReceived事件处理函数，具体的代码不解释了。

写在最后

好了，到这里，我们正式将Windows Phone 7.1中的Push Notification介绍完了。为了增加用户黏性，Push Notification可能是一种非常有效的方式，但是请开发者谨慎使用，如果太多的垃圾信息影响用户体验，那是得不偿失的。另外，我们还需要为Push Notification搭建一个Web服务器，这对于普通开发人员来说，也是一个很难接受的成本。

OpenXLive杯Windows Phone游戏开发大赛

http://www.openxlive.net/posts/news/40

本文链接

Kinect for Windows SDK开发初体验（三）骨骼追踪

2011-06-21T08:16:00Z

作者：马宁

我们的Kinect SDK开发开始渐入佳境了，Skeleton Tracking（骨骼追踪）是Kinect的核心技术，正因为有了这项技术，很多有趣的功能才得以实现。

首先，我们来看一下骨骼追踪的具体实现。Kinect最多可以追踪20个骨骼点，而且目前只能追踪人体，其他的物体或者动物就无能为力了。下图介绍了Kinect骨骼点的分布情况：

初始化代码

接下来，我们来看一下骨骼追踪的代码是如何编写的。首先，我们要创建一个新的Visual C#的工程，叫做“SkeletonTracking”，添加Kinect程序集和Coding4Fun程序集的工作，可以参考上一篇“Kinect for Windows SDK开发初体验（二）操作Camera”的内容，在这里不再重复。

首先我们还是创建Runtime对象，在初始化时，指定UseSkeletalTracking的RuntimeOptions，然后在SkeletonFrameReady事件中添加处理函数。

Runtime nui; 

private void Window_Loaded(object sender, RoutedEventArgs e)

{

nui = new Runtime();

nui.Initialize(RuntimeOptions.UseSkeletalTracking); 

nui.SkeletonFrameReady += new EventHandler<SkeletonFrameReadyEventArgs>(nui_SkeletonFrameReady);

}

接下来，窗体关闭时的事件处理函数：

private void Window_Closed(object sender, EventArgs e)

{

nui.Uninitialize();

}

如果这个时候，我们在空的nui_SkeletonFrameReady事件处理函数中，添加一个断点：

void nui_SkeletonFrameReady(object sender, SkeletonFrameReadyEventArgs e) 

{

}

正确连接Kinect设备，并且站在Kinect前，让Kinect能够正确识别人体时，SkeletonFrameReady事件将被触发。

我们可以通过下图看到返回的事件处理参数，其中比较重要的是SkeletonFrame和Skeletons两个对象。

添加代码

接下来，我们要准备WPF的界面，在界面上添加五个小球，来跟踪头部、双手和膝盖的位置。在MainPage.xaml中，添加下列代码：

<Canvas Name="MainCanvas">
<Ellipse Canvas.Left="0" Canvas.Top="0" Height="50" Name="headEllipse" Stroke="Black" Width="50" Fill="Orange" />
<Ellipse Canvas.Left="50" Canvas.Top="0" Height="50" Name="rightEllipse" Stroke="Black" Width="50" Fill="SlateGray" />
<Ellipse Canvas.Left="100" Canvas.Top="0" Fill="SpringGreen" Height="50" Name="leftEllipse" Stroke="Black" Width="50" />
<Ellipse Canvas.Left="150" Canvas.Top="0" Height="50" Name="KneeRightEllipse" Stroke="Black" Width="50" Fill="Salmon" />
<Ellipse Canvas.Left="200" Canvas.Top="0" Fill="Navy" Height="50" Name="KneeLeftEllipse" Stroke="Black" Width="50" />
</Canvas>

然后，我们在SkeletonFrameReady事件处理函数中添加捕捉SkeletonData的方法：

void nui_SkeletonFrameReady(object sender, SkeletonFrameReadyEventArgs e) 

{

SkeletonFrame allSkeletons = e.SkeletonFrame;

//get the first tracked skeleton

SkeletonData skeleton = (from s in allSkeletons.Skeletons

where s.TrackingState == SkeletonTrackingState.Tracked

select s).FirstOrDefault();

}

我们使用了LINQ来获取TrackingState等于Tracked的SkeletonData数据。在SkeletonData对象的Joints属性集合中保存了所有骨骼点的信息。每个骨骼点的信息都是一个Joint对象，其中的Position的X、Y、Z表示了三维位置。其中X和Y的范围都是-1到1，而Z是Kinect到识别物体的距离。

我们可以用下面的代码，将Joint的位置缩放到合适的比例：

Joint j = skeleton.Joints[JointID.HandRight].ScaleTo(640, 480, .5f, .5f);

最后两个参数为原始大小的最大值和最小值，上面的语句相当于将-0.5到0.5的范围扩大为0到640的范围。

我们封装了一个函数，将获取到的SkeletonData数据，转换为屏幕上的某一个圆圈：

private void SetEllipsePosition(FrameworkElement ellipse, Joint joint) 

{ 

var scaledJoint = joint.ScaleTo(640, 480, .5f, .5f);

Canvas.SetLeft(ellipse, scaledJoint.Position.X);

Canvas.SetTop(ellipse, scaledJoint.Position.Y); 

}

最后，我们SkeletonFrameReady事件的处理方法会是这样的：

void nui_SkeletonFrameReady(object sender, SkeletonFrameReadyEventArgs e) 

{

SkeletonFrame allSkeletons = e.SkeletonFrame;

//get the first tracked skeleton

SkeletonData skeleton = (from s in allSkeletons.Skeletons

where s.TrackingState == SkeletonTrackingState.Tracked

select s).FirstOrDefault();

SetEllipsePosition(headEllipse, skeleton.Joints[JointID.Head]); 

SetEllipsePosition(leftEllipse, skeleton.Joints[JointID.HandLeft]); 

SetEllipsePosition(rightEllipse, skeleton.Joints[JointID.HandRight]);

SetEllipsePosition(KneeLeftEllipse, skeleton.Joints[JointID.KneeLeft]);

SetEllipsePosition(KneeRightEllipse, skeleton.Joints[JointID.KneeRight]);

}

最后，程序运行的效果如下，貌似膝盖的识别还是有些问题：

程序运行时，我们会发现小球运动时会有跳动的问题，为了减少这种情况，我们要设置SkeletonEngine引擎的TransformSmooth属性为true，并指定TransformSmoothParameters参数，根据应用的具体情况，该参数也应该被适当微调。

添加代码后的Load函数，代码如下：

private void Window_Loaded(object sender, RoutedEventArgs e)

{

nui = new Runtime();

nui.Initialize(RuntimeOptions.UseSkeletalTracking); 

//Must set to true and set after call to Initialize

nui.SkeletonEngine.TransformSmooth = true;

//Use to transform and reduce jitter

var parameters = new TransformSmoothParameters

{

Smoothing = 0.75f,

Correction = 0.0f,

Prediction = 0.0f,

JitterRadius = 0.05f,

MaxDeviationRadius = 0.04f

};

nui.SkeletonEngine.SmoothParameters = parameters;

nui.SkeletonFrameReady += new EventHandler<SkeletonFrameReadyEventArgs>(nui_SkeletonFrameReady);

}

写到最后

到这里， Kinect最精华的部分“骨骼追踪”已经介绍给大家了，大家可以去写一些有趣的应用了。接下来，我们会介绍另外一个Kinect的核心功能——Depth Data，景深数据。

OpenXLive杯Windows Phone游戏开发大赛

http://www.openxlive.net/posts/news/40

本文链接

Kinect for Windows SDK开发初体验（二）操作Camera

2011-06-18T11:05:00Z

作者：马宁

Kinect SDK出来之后，不到24小时，很多Geek们已经将自己的示例发布到网上去了。可见，好东西肯定会被大家认可的，不好的东西投入再多的宣传也没用。

这一篇我们就要正式进入Kinect的编程世界了，介绍我们如何从Camera获取图像信息。先来介绍一下Kinect的整体结构，省得大家在后边的介绍中被某些名词弄晕。

Kinect一共有三个Camera，其中中间的一个是RGB Camera，用来获取640x480的彩色图像，每秒钟最多获取30帧图像；两侧是两个景深(3D Depth)传感器，用来检测玩家的相对位置，原理和人眼立体成像是一样的，不过这两个传感器使用的是红外线，所以说奥巴马玩不了Kinect的人一定是居心叵测。Kinect两侧是麦克风，下边还有一个可移动底座，用来调整Kinect的仰角。

Kinect开发环境

今天我们主要是操作RGB Camera和Depth Sensor，首先，我们要完成Kinect开发环境的配置：

第一步，创建WPF工程

打开Visual Studio 2010，创建一个WPF工程，名叫KinectWpfDemo：

当然，由于Kinect SDK中包含基于.NET的程序集，除了WPF外，我们使用.NET WinForm或XNA框架都可以，目前还没有人在Silverlight平台上实验成功。

第二步，添加Kinect程序集的引用

在Solution Explorer中，右键单击KinectWpfDemo，在右键菜单中选择“Add Reference…”。在弹出的对话框中，我们在.NET标签页里，选择“Microsoft.Research.Kinect”程序集。如下图所示：

第三步，添加Coding4Fun Kinect Toolkit

这是一个可选项，不过为了之后的编程方便，建议大家添加一个。Coding4Fun Kinect Toolkit的下载地址：

http://c4fkinect.codeplex.com/

解压缩后，一共有五个文件，针对WinForm、WPF平台，还有一个Microsoft.Expression.Drawing.dll。我们通过Add Reference，将Coding4Fun.Kinect.Wpf.dll添加进来。

获取RGB Camera数据

第四步，添加控件

双击打开MainWindow.xaml，在设计器中添加两个Image控件，一个用于显示RGB图像，另一个用于显示Depth信息。

第五步，引用命名空间

打开MainWindow.xaml.cs文件，在文件头部添加对于Kinect对象的引用：

using Microsoft.Research.Kinect.Nui;

using Microsoft.Research.Kinect.Audio;

using Coding4Fun.Kinect.Wpf;

回到MainWindow.xaml的设计器中，在属性窗口中选择Event，找到Loaded和Closed两个方法，分别双击，添加两个事件的处理函数：

在MainWindow.xaml.cs文件的MainWindow类中，声明Runtime的变量：

Runtime nui;

然后，在Loaded事件的处理函数中添加Runtime初始化的代码：

private void Window_Loaded(object sender, RoutedEventArgs e)

{

nui = new Runtime();

nui.Initialize(RuntimeOptions.UseColor| RuntimeOptions.UseDepth | RuntimeOptions.UseDepthAndPlayerIndex | RuntimeOptions.UseSkeletalTracking);

}

接下来是Closed事件中关闭Runtime的代码：

private void Window_Closed(object sender, EventArgs e)

{

nui.Uninitialize();

}

Runtime对象是Kinect SDK中最主要的一个类，所有针对Kinect的操作都由Runtime类进行了封装。Runtime的构造函数没有接受任何参数，但有一个显式的初始化函数Initialize，接受RuntimeOptions参数，指定调用Kinect的哪些功能。其中RuntimeOptions.UseColor表示使用RGB Camera，而RuntimeOptions.UseDepth则表示使用Depth传感器。

初始化工作完成之后，我们要通过RGB Camera来获取实时的图像数据了。我们首先要声明一个事件处理方法，来接收视频数据的信息：

nui.VideoFrameReady += new EventHandler<ImageFrameReadyEventArgs>(nui_VideoFrameReady);

然后是事件处理函数：

void nui_VideoFrameReady(object sender, ImageFrameReadyEventArgs e)

{

PlanarImage imageData = e.ImageFrame.Image;

image1.Source = BitmapSource.Create(imageData.Width, imageData.Height, 96, 96,

PixelFormats.Bgr32, null, imageData.Bits, imageData.Width * imageData.BytesPerPixel);

//image1.Source = e.ImageFrame.ToBitmapSource();

}

提示：Getting Started上提供的Sample Code有误，需要将最后一个参数中的data.Width改为imageData.Width才可以正常运行。

VideoFrameReady事件会传递一个ImageFrameReadyEventArgs参数给事件处理函数，其中的ImageFrame会包含关于图片的各种信息，比如Type变量指定了图像是来自RGB还是Depth，Resolution变量指定了分辨率，而Image中以byte[]数组的方式保存了图像的真实数据。

然后的工作就是根据PlanarImage中包括的数据来创建一个Bitmap对象，然后将其传递给Image控件，显示到WPF程序的界面上。

最后，我们还要在构造函数里打开视频流，来获取视频数据：

nui.VideoStream.Open(ImageStreamType.Video, 2, ImageResolution.Resolution640x480, ImageType.Color);

第一个参数是ImageStreamType，用来指定打开的设备流类型；第二个参数是PoolSize，指定缓冲区的数量，至少为2，保证一个Buffer进行绘制，另一个Buffer进行数据填充；第三个参数指定Camera的分辨率；第四个参数则是获取的图片类型。

显示效果如下图所示：

上面的示例代码，没有使用Coding4Fun的Helper类，如果使用的话，则代码如下：

void nui_VideoFrameReady(object sender, ImageFrameReadyEventArgs e)

{

image1.Source = e.ImageFrame.ToBitmapSource();

e.ImageFrame.ToBitmapSource().Save("catpure.jpg", ImageFormat.Jpeg);

}

Helper类使用了C#的Extension Methods，为ImageFrame增加了一些转换方法。我们还可以将图像保存为文件，考虑到文件系统存储的效率文件，建议大家不用每张都存。

获取Depth信息

接下来我们要获取Depth信息了，过程与RGB Camera类似。首先要确保Runtime对象被初始化时，已经添加了RuntimeOptions.UseDepth的属性，否则设备无法正常打开。

然后，添加获取Depth数据的事件处理，并打开Depth的数据流，这次的分辨率是320x240：

nui.DepthFrameReady += new EventHandler<ImageFrameReadyEventArgs>(nui_DepthFrameReady);

nui.DepthStream.Open(ImageStreamType.Depth, 2, ImageResolution.Resolution320x240, ImageType.Depth);

下面是事件处理函数，在另外一个Image函数里，显示Depth图像：

void nui_DepthFrameReady(object sender, ImageFrameReadyEventArgs e)

{

image2.Source = e.ImageFrame.ToBitmapSource(); 

}

偷懒，所以使用了Coding4Fun的Helper类。程序运行的效果如下：

写到最后

这一篇中，我们完成了Kinect开发环境的配置、添加了Coding4Fun Kinect Toolkit、从RGB Camera和Depth Sensor中获取了图像信息。

接下来，我们就要进入Kinect动作捕捉部分了。

本文链接

Kinect for Windows SDK开发初体验（一）环境配置

2011-06-16T19:25:00Z

作者：马宁

万众期待的Kinect for Windows SDK终于在广大开发者的千呼万唤中发布了beta版，作为历史上销售最快的消费电子产品，早就有无数人想将其用于其他领域了。微软虽然在硬件接口上制造了一点小障碍，但并没有对Kinect的输出做任何加密。于是，基于Kinect的各种应用层出不穷，也有开源社区提供了针对Kinect的USB驱动程序，比如OpenKinect等。

微软从谏如流，推出了官方版的Kinect for Windows SDK，终于让广大开发者可以名正言顺地使用Kinect SDK了。我希望能够在第一时间为国内开发者提供Kinect开发相关的介绍，根据微软官方提供的指南，从浅入深，将自己摸索Kinect SDK 的过程记录下来。

安装环境

首先来说，Kinect for Windows SDK的下载地址：

http://research.microsoft.com/en-us/um/redmond/projects/kinectsdk/download.aspx

Kinect SDK目前只支持Windows 7，分为x86和x64两个版本。开发工具方面还需要.NET Framework 4.0和Visual Studio 2010 （最低Express版本）的支持。

Kinect SDK的视频开发教程：

http://channel9.msdn.com/Series/KinectSDKQuickstarts?sort=recent#tab_sortBy_recent

Kinect SDK的开发指南：

http://research.microsoft.com/en-us/um/redmond/projects/kinectsdk/guides.aspx

Kinect SDK的官方论坛：

http://social.msdn.microsoft.com/Forums/en-US/kinectsdk/threads

硬件设备的需求是：Kinect for Xbox 360 sensor和Xbox 360 Kinect AC Adapter/ Power Supply。

如果您购买的是单独的Kinect，将包含Kinect AC Adapter/ Power Supply。但是如果您购买的是XBOX 360 Slim和Kinect的套装，就需要单独购买Kinect AC Adapter/ Power Supply。下面是亚马逊上的产品链接：

http://www.amazon.com/Xbox-360-Kinect-Adapter-Power-Supply/dp/B004IXRXGY/ref=sr_1_1?ie=UTF8&qid=1308247174&sr=8-1

安装步骤

1. 硬件安装

下面的图片是Kinect和AC Adapter/ Power Supply：

按照接口连接好后，将USB插入到PC上，AC Adapter电源是可以支持220V的，所以不需要转换器直接插到电源上就可以。

2. Kinect SDK安装

Kinect SDK的安装过程非常简单，无需任何设置，直接安装即可。

3. 环境测试

Kinect SDK安装完成后，我们将Kinect转接口的USB接口插入到PC中。PC会发现新硬件，并且自动查找驱动程序安装。下图是安装完成后的示意图：

4. 测试程序

我们打开Kinect SDK中自带的Sample Skeletal Viewer就可以很方便地检测Kinect设备是否与PC已经连接好了。

为了测试，逼得我不得不闪亮出镜了。以后Kinect调试，说不定还真要请一个人站在那里，实现敏捷开发中的“双人编程”……

写到最后

我们今天关于Kinect的介绍就到这里，在Kinect SDK的发布会上展示了很多有意思的DEMO，可见Kinect的应用前景是无限广阔的。下图就是一个Kinect与虚拟增强现实整合的案例：

下一节，我们会深入Kinect真实的开发环境，来编写第一个Kinect的应用程序。

本文链接

马宁的Windows Phone 7.1初体验——XNA与Silverlight集成

2011-06-16T16:14:00Z

关于Windows Phone Mango真真假假的图片、视频已经在网上流传很久了，微软发布的Windows Phone 7.1 SDK可以让我们看到一部分Mango支持的功能。

普通用户对Mango的关注更多停留在多语言、多任务等方面，但对于开发者来说，Mango还有很多有趣的功能。我会试着将自己感兴趣的一些功能写出来，变成一个系列。

首先，大家要安装Windows Phone 7的SDK和Windows Phone 7.1 SDK的Beta 版，下载地址如下：

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=77586864-ab15-40e1-bc38-713a95a56a05

创建工程

关于Windows Phone 7.1的第一个功能是XNA与Silverlight的集成。Windows Phone里有两个Framework，Silverlight是做应用的，而XNA是做游戏开发的。Silverlight有一套非常好用的UI设计工具和控件体系，而XNA对于动画效果的处理又远远超过Silverlight。但是在WP7里，Silverlight和XNA必须是分开的，所以当Silverlight应用需要高性能显示，或者XNA游戏里需要编写UI时，都会碰到很多困难。

于是，在WP 7.1里，提供了XNA与Silverlight集成的功能。接下来，我们就来看一下，如何创建一个Silverlight和XNA集成的应用。

打开Visual Studio 2010，选择File-New Project，在Visual C#里找到Silverlight for Windows Phone，然后选择其中的“Windows Phone 3D Graphics Application”，这个名字有足够的迷惑性，XNA的2D也是支持的。如下图：

创建过程没有什么特殊的地方，创建完成后的工程如下图所示：

说实话，XNA与Silverlight集成的实现并不算优雅，有点叠床架屋的感觉。整个Solution里分为三个Project，其中GraphicsApp1是我们的主程序，主要的逻辑代码都是在这个工程里的，这是一个典型的Silverlight程序，包含了App.xaml和MainPage.xmal，多出来一个GamePage.xaml，这个是XNA的页面。除此之外，还有两个Library，分别叫做GraphicsApp1Library和GraphicsApp1LibraryContent，后边是XNA的Content库，前边一个应该是为了能够让Silverlight加载XNA资源所做的适配库。

直接运行程序，我们会看到下面的界面，点击HomePage的Play按钮，我们就进入了XNA的GamePage界面：

GamePage探秘

接下来，我们看一下GamePage.xaml的结构，看看这个看似普通的XAML页面里具体做了什么事情。首先是GamePage.xaml，如下：

<phone:PhoneApplicationPage 
    x:Class="GraphicsApp2.GamePage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
    xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    FontFamily="{StaticResource PhoneFontFamilyNormal}"
    FontSize="{StaticResource PhoneFontSizeNormal}"
    Foreground="{StaticResource PhoneForegroundBrush}"
    SupportedOrientations="Portrait" Orientation="Portrait"
    mc:Ignorable="d" d:DesignHeight="800" d:DesignWidth="480"
    shell:SystemTray.IsVisible="False">

    <!--No XAML content as the page is rendered entirely with XNA-->
    
</phone:PhoneApplicationPage>

什么都没有……所有的显示都是由XNA控制的。接下来，我们去看GamePage.xaml.cs，首先来看引用程序集的部分：

using Microsoft.Xna.Framework;

using Microsoft.Xna.Framework.Content;

using Microsoft.Xna.Framework.Graphics;

引用了三个XNA的命名空间，接下来是变量声明：

GameTimer timer;

ContentManager content;

SpriteBatch spriteBatch;

Texture2D texture;

Vector2 spritePosition;

除了GameTimer是生面孔外，其他几个都是老熟人，GameTimer也好理解，Silverlight是事件驱动的Framework，如果想定时更新的话，必须要加入一个Timer。接下来，是GamePage的构造函数：

public GamePage()
        {
            InitializeComponent();

            // Get the application's ContentManager
            content = (Application.Current as App).Content;

            // Create a timer for this page
            timer = new GameTimer();
            timer.UpdateInterval = TimeSpan.FromTicks(333333);
            timer.Update += OnUpdate;
            timer.Draw += OnDraw;
        }

ContentManager对象是来自于App的Content属性，我们不会再有一个派生自Microsoft.Xna.Framework.Game的Host类了。然后是GameTimer的初始化工作，指定更新时间间隔，然后为Update和Draw事件添加方法。我不知道理解的是否正确，但有可能是GameTimer类重新实现了XNA Framework的机制。

然后是两个重载的Navigated函数：

protected override void OnNavigatedTo(NavigationEventArgs e)
        {
            // Set the sharing mode of the graphics device to turn on XNA rendering
            SharedGraphicsDeviceManager.Current.GraphicsDevice.SetSharingMode(true);

            // Create a new SpriteBatch, which can be used to draw textures.
            spriteBatch = new SpriteBatch(SharedGraphicsDeviceManager.Current.GraphicsDevice);

            // TODO: use this.content to load your game content here

            // Start the timer
            timer.Start();

            base.OnNavigatedTo(e);
        }

        protected override void OnNavigatedFrom(NavigationEventArgs e)
        {
            // Stop the timer
            timer.Stop();

            // Set the sharing mode of the graphics device to turn off XNA rendering
            SharedGraphicsDeviceManager.Current.GraphicsDevice.SetSharingMode(false);

            base.OnNavigatedFrom(e);
        }

OnNavigatedTo函数实现了LoadContent的功能，第一句话值得注意，我们要首先打开GraphicsDevice的SetSharingMode为true，才能够让XNA元素正常的显示出来。这句话也交代了XNA最主要的类GraphicsDeviceManager的去向，被放到一个静态的SharedGraphicsDeviceManager对象里去了。

创建SpriteBatch和加载资源的过程不再叙述，最后要调用GameTimer的Start方法，来启动XNA的时间驱动机制，与之对应的是OnNavigatedFrom函数中，我们还需要调用GameTimer的Stop方法，来关闭时间驱动机制。

最后是熟悉的OnUpdate和OnDraw方法，就数这两个函数原汁原味地保留了XNA的特点。

/// <summary>
        /// Allows the page to run logic such as updating the world,
        /// checking for collisions, gathering input, and playing audio.
        /// </summary>
        private void OnUpdate(object sender, GameTimerEventArgs e)
        {
            // TODO: Add your update logic here
        }

        /// <summary>
        /// Allows the page to draw itself.
        /// </summary>
        private void OnDraw(object sender, GameTimerEventArgs e)
        {
            SharedGraphicsDeviceManager.Current.GraphicsDevice.Clear(Microsoft.Xna.Framework.Color.CornflowerBlue);

            // TODO: Add your drawing code here
        }

添加Silverlight控件

如果只是在Silverlight应用里添加一个XNA的页面，恐怕还没有太大的吸引力。我们还应该让XNA和Silverlight能够在一个页面上显示。首先我们要打开GamePage.xaml文件，找到下面的代码：

<!--No XAML content as the page is rendered entirely with XNA-->

将下列代码替换上面的注释：

<!-- LayoutRoot is the root grid where all page content is placed -->
    <Grid x:Name="LayoutRoot">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="*"/>
            <RowDefinition Height="Auto"/>
        </Grid.RowDefinitions>

        <!-- Toggles the visibility of the ColorPanel -->
        <Button Grid.Row="0" x:Name="ColorPanelToggleButton" Click="ColorPanelToggleButton_Click" Margin="1,0,-1,0">Toggle Color Panel</Button>

        <!-- Arrange buttons in a horizontal line by using StackPanel -->
        <StackPanel x:Name="ColorPanel" Grid.Row="2"  Height="100" Orientation="Horizontal" HorizontalAlignment="Center" Visibility="Visible">
            <!-- Buttons to set the rectangle to specific colors -->
            <Button Click="redButton_Click" HorizontalAlignment="Center" Height="75" VerticalAlignment="Center" BorderThickness="3" Background="Firebrick" Width="75" />
            <Button Click="greenButton_Click" HorizontalAlignment="Center" Height="75" VerticalAlignment="Center" BorderThickness="3" Background="Lime" Width="75" />
            <Button Click="blueButton_Click" HorizontalAlignment="Center" Height="75" VerticalAlignment="Center" BorderThickness="3" Background="Blue" Width="75" />
        </StackPanel>
    </Grid>

如果编译的话，会提示没有Button对应的事件处理函数。

添加代码

下面部分和MSDN提供的示例代码不同，我试图找到一种更简单的办法来更改颜色。首先，我们在GraphicsApp1LibraryContent工程里找到redRect.jpg，右键单击，选择Open With，然后在列表里选择Paint，用画图打开文件后，将整个图片涂成白色。做完这个工作后，记得一定要重新编译整个工程。

接下来，我们声明Color变量，并且在构造函数里赋初始值。

Color bgColor;

public GamePage()

{

    // ...
 
    bgColor = Color.Red;

}

然后我们增加事件处理函数，首先是控制颜色是否显示的控件：

// Toggle the visibility of the StackPanel named "ColorPanel"
        private void ColorPanelToggleButton_Click(object sender, RoutedEventArgs e)
        {
            if (System.Windows.Visibility.Visible == ColorPanel.Visibility)
            {
                ColorPanel.Visibility = System.Windows.Visibility.Collapsed;
            }
            else
            {
                ColorPanel.Visibility = System.Windows.Visibility.Visible;
            }
        }

然后是切换颜色的几个Button的处理函数：

// Switch to the red rectangle
        private void redButton_Click(object sender, RoutedEventArgs e)
        {
            bgColor = Color.Red;
        }

        // Switch to the green rectangle
        private void greenButton_Click(object sender, RoutedEventArgs e)
        {
            bgColor = Color.Green;
        }

        // Switch to the blue rectangle
        private void blueButton_Click(object sender, RoutedEventArgs e)
        {
            bgColor = Color.Blue;
        }

最后，我们在OnDraw函数里，找到下面的代码：

spriteBatch.Draw(texture, spritePosition, Color.White);

换成下面的代码：

spriteBatch.Draw(texture, spritePosition, bgColor);

这样我们就可以为白色的材质绘制出不同的颜色了。

现在程序可以编译通过了，但是运行程序后，Silverlight的控件却没办法显示出来。原因是Silverlight控件必须经过特殊的处理，才能够显示出来。首先要声明一个UIElementRenderer变量：

// For rendering the XAML onto a texture

UIElementRenderer elementRenderer;

然后，在GamePage的构造函数里，添加下面的代码：

// Use the LayoutUpdate event to know when the page layout 

// has completed so we can create the UIElementRenderer

LayoutUpdated += new EventHandler(GamePage_LayoutUpdated);

添加GamePage_LayoutUpdated的函数，在函数中创建UIElementRenderer的对象：

void GamePage_LayoutUpdated(object sender, EventArgs e)
        {
            // Create the UIElementRenderer to draw the XAML page to a texture.

            // Check for 0 because when we navigate away the LayoutUpdate event
            // is raised but ActualWidth and ActualHeight will be 0 in that case.
            if (ActualWidth > 0 && ActualHeight > 0 && elementRenderer == null)
            {
                elementRenderer = new UIElementRenderer(this, (int)ActualWidth, (int)ActualHeight);
            }
        }

最后，在OnDraw函数里，添加下面的代码：

/// <summary>
        /// Allows the page to draw itself.
        /// </summary>
        private void OnDraw(object sender, GameTimerEventArgs e)
        {
            SharedGraphicsDeviceManager.Current.GraphicsDevice.Clear(Color.Black);

            // TODO: Add your drawing code here
            // Render the Silverlight controls using the UIElementRenderer
            elementRenderer.Render();


            // Draw the sprite
            spriteBatch.Begin();
            spriteBatch.Draw(texture, spritePosition, bgColor); //Color.White);
            spriteBatch.DrawString(StartFont, "Hello, XNA", new Vector2(50), Color.Blue);

            // Using the texture from the UIElementRenderer, 
            // draw the Silverlight controls to the screen
            spriteBatch.Draw(elementRenderer.Texture, Vector2.Zero, Color.White);


            spriteBatch.End();
        }

再运行程序时，我们就可以看到Silverlight控件了，点击颜色控件，方块会切换成对应的颜色。如下图所示：

加载XNA资源

到这里，我们的体验基本上告一段落了，但是我试了一下是否能够正常加载XNA的字体，所以就写了最后这部分。

右键点击GraphicsApp1LibraryContent，选择Add – New Item。在对话框中选择Sprite Font，我们将字体命名为StartFont。在打开的字体文件中，我们将Size改成30，如下面所示：

<!--
    Size is a float value, measured in points. Modify this value to change
    the size of the font.
    -->
    <Size>30</Size>

回到GamePage.xaml.cs文件中，我们首先声明SpriteFont变量：

SpriteFont StartFont;

然后，在OnNavigatedTo函数中，添加字体加载的代码：

protected override void OnNavigatedTo(NavigationEventArgs e)
        {

            // Set the sharing mode of the graphics device to turn on XNA rendering
            SharedGraphicsDeviceManager.Current.GraphicsDevice.SetSharingMode(true);

            spriteBatch = new SpriteBatch(SharedGraphicsDeviceManager.Current.GraphicsDevice);

            // TODO: use this.content to load your game content here
            texture = content.Load<Texture2D>("redRect");
            StartFont = content.Load<SpriteFont>("StartFont");

最后，在OnDraw函数里，添加字体的绘制函数：

spriteBatch.DrawString(StartFont, "Hello, XNA", new Vector2(50), Color.Blue);

程序运行的效果如下：

另一条路

除了在Silverlight for Windows Phone创建Windows Phone 3D Graphics Application外，我们还能够通过另一种方式创建XNA与Silverlight整合的应用程序。

在XNA Game Studio 4.0中，选择Windows Phone Rich Graphics Application：

通过这个向导创建的程序，与上面创建的程序大同小异，只是界面略有不同。运行界面如下：

写在最后

好了，到这里，我们正式将Windows Phone 7.1中的Silverlight与XNA整合应用介绍完了。在XNA游戏中，我们可以使用Silverlight来创建界面；也可以在Silverlight应用中编写高性能的3D界面。

OpenXLive杯Windows Phone游戏开发大赛

http://www.openxlive.net/posts/news/40

本文链接

如何将OpenXLive添加到WP7 Silverlight游戏中

2011-04-02T07:06:00Z

OpenXLive beta版发布已经有一个半月的时间了，得到了开发者和玩家的好评，目前已经有五款OpenXLive游戏进入Windows Phone Marketplace，其中的7bomb和Super Hoops都取得了非常骄人的成绩。

当OpenXLive在XNA游戏中大展身手的同时，我们也听到了一些来自Silverlight程序员的抱怨。在Windows Phone 7中虽然提供了XNA的游戏开发平台，但相当一部分的游戏是采用Silverlight开发的。毕竟对于显示性能不高的游戏来说，Silverlight是一个颇具魅力的快速开发工具。

幸好，我们在最初的架构设计上考虑了未来支持Silverlight的可能性，所以将业务逻辑部分封装到了OpenXLive.dll中，而将XNA上的XLiveForm窗体和控件库封装到了OpenXLive.Forms.dll中。我们只需要在Silverlight中调用OpenXLive中的功能即可。

在提供了一个OpenXLive on Silverlight的简单示例代码后，我们发现对Silverlight游戏的支持仍旧不够。首先，我们只提供了Leaderboard部分的示例代码，在缺乏文档的情况下，开发其他功能的UI是很困难的；其次，开发者并不希望自己动手写一个Silverlight UI，而只是想简单地在游戏中加入OpenXLive的支持，就像在XNA游戏中那样。

所以，我们重新定义了OpenXLive Silverlight的功能，实现了OpenXLive中的所有功能，并将其封装到了OpenXLive.Silverlight.dll中。在开发过程中，我们尽力保持XNA和Silverlight框架的一致性，如果您使用过OpenXLive XNA版本，在Silverlight版本中，您会有一种似曾相识的感觉，这正是我们所希望的。

需要提示的一点是，OpenXLive的Silverlight和XNA版本共同使用了一个逻辑程序集——OpenXLive.dll，所以他们在功能上是一致的。

未来，我们会将OpenXLive Silverlight加入到OpenXLive SDK中，并提供Visual Studio模板。在某一个时间点上，我们会考虑对OpenXLive Silverlight进行开源，让开发者能够方便的将OpenXLive Silverlight修改成自己想要的样子。

OpenXLive简介

微软为Windows Phone 7上的XNA和Silverlight游戏开发提供了非常好的开发工具和应用程序框架，使得开发者可以更加容易地开发出生动有趣的游戏来。但是随着开发的深入，我们发现，虽然我们开发的游戏品质可以和大公司的产品相媲美，但比起大公司游戏的用户体验还是相差很多。因为，我们必须将很多时间用于周边功能的开发，比如：启动界面(Splash Screen), 积分榜(Leaderboard)和游戏成就(Achievement)等，更不要奢谈为游戏加入SNS功能，比如：查看在线用户(Online Player)、云存储(Cloud Storage)等在线功能了。这些周边功能的开发时间，可能要超过游戏本身的开发时间，那我们该怎么办呢？

OpenXLive正在想办法帮助个人开发者和小团队开发者，使他们在最短的时间内拥有以上这些只有大公司才可能拥有的游戏功能。

OpenXLive是一种为Windows Phone 7智能手机游戏开发者提供的云端在线服务。支持开发者为单机游戏增加云端和SNS功能，帮助开发者以最小的工作量将云端服务集成到自己的游戏中。这些云端服务包括：积分榜、游戏成就、在线对战、Social Network和云端存储等功能。与Open XLive类似的服务，还有iOS上的OpenFeint。

OpenXLive目前支持Windows Phone的XNA与Silverlight开发框架，不需要开发者编写UI代码，即可在游戏中方便地调用OpenXLive的界面及功能。由于XNA和Silverlight是两个不同的应用程序框架，所以，OpenXLive提供了不同的引用方式来支持XNA和Silverlight游戏。

本文讨论的是如何将OpenXLive加入到Silverlight游戏中，如果您的游戏采用XNA编写，请查看《OpenXLive开发入门》，链接如下：

http://wiki.openxlive.net/Getting-Started-with-Open-XLive.ashx

添加引用

您可以在下面的链接中下载单独的OpenXLive Silverlight SDK:

http://resource.openxlive.com/resource/Download/ad686043-d477-4d5a-bc83-f27520a3d600

首先，我们假设您已经有了基于Silverlight开发的Windows Phone游戏。如果您想从头创建一个OpenXLive Silverlight游戏，您可以参考下一节《OpenXLive Silverlight向导使用》。

我们采用的示例工程OpenXLiveGameSilverlight，您可以在OpenXLive的资源网站中找到。

首先，我们在OpenXLive SDK的bin文件夹下找到OpenXLive.dll和OpenXLive.Silverlight.dll，将其拷贝到工程所在的目录中。

然后，在Visual Studio 2010中，打开OpenXLiveGameSilverlight工程，在Solution Explorer中找到References节点，右键单击啊，选择Add References，在对话框中选择Browse页面，找到工程目录下的OpenXLive.dll和OpenXLive.Silverlight.dll，将两个程序集的引用加入到工程中。

添加成功后，如下图所示：

修改初始页面

在引用添加完成之后，我们还要修改WMAppMainifest.xml文件，使Silverlight游戏启动时，启动OpenXLive.Silverlight中所包含的Startup页面。

在工程的Propertes节点下找到WMAppMainifest.xml文件，双击打开，如下图所示：

WMAppMainifest.xml文件的结构如下：

<?xml version="1.0" encoding="utf-8"?>

<Deployment xmlns="http://schemas.microsoft.com/windowsphone/2009/deployment" AppPlatformVersion="7.0">
  <App xmlns="" ProductID="{3cf35939-f7f6-4808-969c-22d520f6a526}" Title="OpenXLiveGameSilverlight" RuntimeType="Silverlight" Version="1.0.0.0" Genre="apps.normal"  Author="OpenXLiveGameSilverlight author" Description="Sample description" Publisher="OpenXLiveGameSilverlight">
    <IconPath IsRelative="true" IsResource="false">ApplicationIcon.png</IconPath>
    <Capabilities>
      <Capability Name="ID_CAP_GAMERSERVICES"/>
    </Capabilities>
    <Tasks>
      <DefaultTask  Name ="_default" NavigationPage="OpenXLive.Silverlight;component/Forms/StartupPage.xaml"/>
    </Tasks>
    <Tokens>
      <PrimaryToken TokenID="OpenXLiveGameSilverlightToken" TaskName="_default">
        <TemplateType5>
          <BackgroundImageURI IsRelative="true" IsResource="false">Background.png</BackgroundImageURI>
          <Count>0</Count>
          <Title>OpenXLiveGameSilverlight</Title>
        </TemplateType5>
      </PrimaryToken>
    </Tokens>
  </App>
</Deployment>

在WMAppMainifest.xml文件中找到DefaultTask节点，并将其中的NavigationPage改为”OpenXLive.Silverlight;component/Forms/StartupPage.xaml”。这样能保证Silverlight游戏启动之后，会首先启动OpenXLive的Startup页面。

接下来，我们还要完成对XLiveSLFormManager对象的初始化工作。打开工程中的App.xaml.cs文件，首先在文件顶部加入对OpenXLive.Silverlight的引用：

using OpenXLive.Silverlight;

然后，在App类中找到Application_Launching方法，加入XLiveSLFormManager对象的创建操作：

// Code to execute when the application is launching (eg, from Start)
        // This code will not execute when the application is reactivated
        private void Application_Launching(object sender, LaunchingEventArgs e)
        {
            XLiveSLFormManager manager = new XLiveSLFormManager(this, "xxxxxxxxxxxxxxxx");
        }

其中，第一个参数为App实例的引用，第二个参数为SecretKey，该Key是在OpenXLive网站上创建游戏时，由系统生成的，作为OpenXLive系统识别游戏的唯一标识符，请保证这个SecretKey的安全，以防止其他游戏进行仿冒。

更多详细情况，请查看《在开发者网站上创建OpenXLive游戏》，链接如下：

http://wiki.openxlive.net/Tutorial-4-Create-OpenXLive-Game-in-website.ashx

当然，我们也可以在App类中创建一个static的FormManager属性，用于在程序的其他地方调用XLiveSLFormManager对象，但这一步不是必须的，代码如下：

public static XLiveSLFormManager FromManager { get; internal set; }

        // Code to execute when the application is launching (eg, from Start)
        // This code will not execute when the application is reactivated
        private void Application_Launching(object sender, LaunchingEventArgs e)
        {
            FromManager = new XLiveSLFormManager(this, "xxxxxxxxxxxxxxxxxx");
        }

我们运行程序，能够看到下面的界面，是不是有一种似曾相识的感觉？点击Game Center和Leaderboards，我们可以进入相关的界面：

目前OpenXLive Silverlight只支持竖屏（Portrait）显示，未来我们会加入对于横屏（Landscape）的支持。另外，除了Startup界面之外，其他OpenXLive界面都是黑色背景，这样做主要是为了节省系统资源。

添加背景和事件处理

接下来，为了美化启动界面，我们要加入背景图片。添加背景图片的操作非常简单：在Solution Explorer中，选择Project节点，右键单击，选择Add – Existing Item，在选择一副PNG或JPG的图片，尺寸最好是800x480，这样能够有效保证图片不变形。

另外请确认一下，我们加入的图片Build Action为Resource，且Copy to Output Directory选择“Do not copy”。

然后，回到App.xaml.cs文件的Application_Launching方法中：

// Code to execute when the application is launching (eg, from Start)
        // This code will not execute when the application is reactivated
        private void Application_Launching(object sender, LaunchingEventArgs e)
        {
            FromManager = new XLiveSLFormManager(this, "xxxxxxxxxxxxxxxxxxx");
            StartupPage.BackgroundPath = "/OpenXLiveGameSilverlight;component/OpenXLive.Portrait.png";
        }

我们要为StartupPage添加BackgroundPath，示例代码的写法是针对游戏本身的资源，也可以指定一个来自Web的链接，不过出于显示效果的考虑，建议您不要这么做。OpenXLiveGameSilverlight，是资源所在程序集的名称；component/OpenXLive.Portrait.png，是资源的引用路径，如果资源包含在一个文件夹中，写法应该是component/MyFolder/OpenXLive.Portrait.png。

最后提醒，请大家千万不要忘记字符串前面的“/”，没有这个符号，程序将抛出异常。

接下来，我们要加入Startup页面的事件处理函数，当用户点击某一个按钮时，会触发一个事件操作。我们在下面增加了其中两个按钮的事件处理方法：

public static XLiveSLFormManager FromManager { get; internal set; }

        // Code to execute when the application is launching (eg, from Start)
        // This code will not execute when the application is reactivated
        private void Application_Launching(object sender, LaunchingEventArgs e)
        {
            FromManager = new XLiveSLFormManager(this, "xxxxxxxxxxxxxxxxxx");
            StartupPage.BackgroundPath = "/OpenXLiveGameSilverlight;component/OpenXLive.Portrait.png";
            StartupPage.NewGameButtonClick += new EventHandler(StartupPage_NewGameButtonClick);
            StartupPage.AboutButtonClick += new EventHandler(StartupPage_AboutButtonClick);
        }

        void StartupPage_AboutButtonClick(object sender, EventArgs e)
        {
            MessageBox.Show("OpenXLive Silverlight Demo 1.0");
        }

        void StartupPage_NewGameButtonClick(object sender, EventArgs e)
        {
            this.RootFrame.Navigate(new Uri("/MainPage.xaml", UriKind.Relative));
        }

AboutButtonClick的处理函数非常简单，只是调用了Message来显示游戏的版本信息。而NewGameButtonClick则是为了调用开发人员自己编写的Silverlight游戏界面，这个界面应该存在于Silverlight游戏的程序集中。

最后，我们得到的Silverlight启动界面就是上图这样。我们在Silverlight的界面中，没有增加Exit选项，因为Silverlight界面默认不支持退出操作，只能通过按Back键来退出程序。

使用Wizard创建新游戏

接下来，我们要介绍如何使用Visual Studio 2010的Template来创建一个OpenXLive Silverlight游戏。OpenXLive Silverlight的模板会包括在OpenXLive SDK中，如果您安装了OpenXLive SDK，就可以在Visual Studio 2010中创建基于Silverlight的游戏了。

首先，打开Visual Studio 2010，在File菜单中选择New-Project，在New Project对话框中，选择Visual C#下的Silverlight for Windows Phone中的OpenXLive Silverlight节点，然后选择创建OpenXLiveSilverlightGame。

OpenXLiveSilverlightGame工程创建完毕后，如果直接编译，会得到下列的错误提示：

这个错误是为了提醒开发者，要在OpenXLive开发者网站上创建自己的游戏，获取游戏对应的Secret Key，才能够正常使用OpenXLive的在线功能。

获取Secret Key的方法，请参考《在开发者网站上创建OpenXLive游戏》，链接如下：

http://wiki.openxlive.net/Tutorial-4-Create-OpenXLive-Game-in-website.ashx

打开App.xaml.cs文件，找到下面的代码：

public static XLiveSLFormManager FromManager { get; internal set; }

#error Please full your game Secret Key in below code
private string APISecretKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxx";

// Code to execute when the application is launching (eg, from Start)
// This code will not execute when the application is reactivated
private void Application_Launching(object sender, LaunchingEventArgs e)
{
    FromManager = new XLiveSLFormManager(this, APISecretKey);
    StartupPage.BackgroundPath = "/OpenXLiveSilverlightGame2;component/OpenXLive.Portrait.png";
    StartupPage.NewGameButtonClick += new EventHandler(StartupPage_NewGameButtonClick);
    StartupPage.AboutButtonClick += new EventHandler(StartupPage_AboutButtonClick);
}

开发者将Secret Key加入到高亮显示部分，并且注释掉#error代码，我们的工程就可以正常编译了。

我们也可以修改New Game Button的事件处理函数，来决定调用哪个Silverlight窗体。

void StartupPage_NewGameButtonClick(object sender, EventArgs e)
{
    this.RootFrame.Navigate(new Uri("/MainPage.xaml", UriKind.Relative));
}

到这里，我们就介绍完了如何通过Visual Studio 2010向导来创建OpenXLive Silverlight游戏的方法。

写在最后

我们用几乎与XNA版本相同的顺序，叙述了如何将OpenXLive Silverlight加入到Windows Phone Silverlight的游戏中去。接下来，我们会介绍，如何提交成绩、提交成就，考虑到Silverlight的界面编程更加容易，我们并不会提供一个标准的成绩提交界面，该界面只会以示例代码的形式出现。

http://wiki.openxlive.net/OpenXLive-Silverlight.ashx

引用

OpenXLive官方网站

http://www.openxlive.net/

OpenXLive开发者网站

http://developer.openxlive.net/

OpenXLive开发入门

http://wiki.openxlive.net/Getting-Started-with-Open-XLive.ashx

本文链接

Game Center，移动游戏社交平台的勘探报告

2011-03-31T06:13:00Z

Game Center，移动游戏社交平台的勘探报告

作者：马宁

缘起

亲爱的朋友，

当你读到这封信的时候，我们已经在路上了。南加州发现了金矿，先到那里的人会赢得鲜花、掌声，以及足以笑傲未来十年的资本。是的，我们站在移动互联网的破晓之时，这与淘金时代是多么的相似，每个人都狂热地进入这个领域，宣称自己拥有最先进的设备，足以找到地下深埋的黄金。资本的追捧，也让耐心与沉着离我们而去。

作为一个赶上互联网泡沫结尾的程序员，在我的记忆中，如今的互联网巨头都是活过了严冬的幸存者，上一个世纪里那些为怎么花钱发愁的互联网公司已经变成了遥远而古老的回忆，甚至已经无人记起，宛如南加州沙漠里的一颗沙砾。

无论如何，移动互联网时代的巨人们已经在路上了，虽然在熙熙攘攘的人群里，他们是那么的不起眼，甚至还有一些寒酸。吃苦、技术，外加一点点运气，这是未来的巨人们手里仅有的武器，我们不必指点江山，任何一座山下埋藏的宝藏就足以创造一个时代的王者了，接下来的问题就是如何找到这些宝藏。

我们都知道，这个移动互联网时代的起源是一家Apple的公司发布一款叫做iPhone的智能手机，但一款手机不足以颠覆PC与互联网时代，吹响安魂曲的是一个叫做App Store的服务。

一句话概括，App Store让软件分发渠道从少数顶尖软件公司的手里解放出来，让小团队和个人开发者的应用可以直接与最终用户见面。这就像真人秀的节目一样，冠军就在选手之中，可是谁也不知道冠军是谁。每一个参赛者不是为了争取一份养活自己的收入，而是为了获得最后的大奖。于是，无数的创富奇迹被有意或无意地创造出来了。目前，这个有30万参赛者的真人秀节目，已经有了第一季的冠军，是的，它来自北欧，一个因为长夜漫漫而盛产程序员的地方。

其他的手机厂商也在模仿，所以，我们将App Store称之为一种模式，在另外一些厂家嘴里，叫做Marketplace。

接下来，我们所谈论的一切，都是建筑在App Store这种新的分销模式之上，App Store将彻底改变整个计算机世界的体系与灵魂。

Service + Client

我们来描绘一下移动互联网时代的蓝图吧，尽管已经有无数人对此有了专门的论述，其中颇为著名的就是《长尾理论》。

当产品展示的成本趋近于零，为用户提供越多的产品，就能够获取越丰厚的利润，因为再小众的产品也有被消费的需求。而App Store几乎就是长尾理论在移动互联网上的完美实现。

而App Store的另一大贡献是整齐划一的定价原则，大部分应用都以 0.99美金的价格销售，这一点来自于Apple另一个成功的在线服务——iTunes。说到“微创新”，Apple才是微创新的大师，Apple在产品创新上极为谨慎，几乎每一个成功的产品总有上一个成功产品的影子。

所以，App Store上的应用被极度细分，每一个功能都会成为一个单独的应用。而在App Store之前，大的软件公司总是试图在一个产品里塞入更多的功能，这主要是为了解释软件为什么要卖那么贵，于是用户经常为一个功能而购买了一个包含几十项功能的工具包。其实，真正的成本来源于软件分发渠道，消费者50%的价格是支付给零售渠道的（这个情况，在各个国际地区会有很大差距，所以这个结论不包括中关村那些抱孩子的妇女）。

回过头来看，App Store 3：7的分成比例，其实真的已经非常合理了，当然App Store也没有为店面、物流而增加任何成本，因为……商店开在每个人的手机上。

反过来看App Store对于开发者的影响，首先是小团队和个人开发者获得了前所未有的机会；其次是应用程序的小品化，每一个功能都可以成为一个软件；然后，客户端应用将在移动设备上的主流，70%的功能会来自客户端应用。也许很多人会寄希望于HTML 5，如果你相信几个心怀鬼胎的宿敌能够为了统一的互联网而努力奋斗，那么我无话可说。悄悄的说，你没发现几个主流智能手机平台间的开发环境是越差越多了吗？注：拍我之前请先拍死《Web已死》。

接下来是什么？在线公共服务受到热捧。虽然Facebook在互联网上获得了巨大的成功，但我们应该将其视为一家移动互联网公司，因为40%的用户会通过移动设备来访问Facebook。这只是表象，真正的原因是Facebook提供了一套完整的API，允许各种应用（不仅限于移动设备上的应用）接入Facebook的服务之中。

于是，Facebook不提供任何的应用和功能，只提供一个高达五亿的用户关系图谱，以及相关的图片、信息、身份验证的服务。无数的应用及游戏为了拥有这张关系图谱，而选择接入Facebook的系统，于是Facebook就拥有了无数的游戏和应用，而衍生的广告和支付服务，还可以帮Facebook获取利润。用户是我的，什么都是我的，Facebook如是说。

而且Facebook已经为进入移动互联网做好了准备，这一点从其开发者网站上，将Mobile App作为单独的分类出现就可以看出来。通过API接入的方式，让Facebook远离了多变的用户需求和难以捉摸的用户体验，让他们关注于自己的核心价值——人与人的关系。当别人还在关注Web端的展现时，Facebook已经在关注以Client为核心的下一代移动互联网了。与此类似的是Twitter，与Facebook关注于人与人之间的关系不同，Twitter更像是一个信息传递的媒体，Twitter本身就是为手机准备的，比如140个字的限制就来源于SMS的技术瓶颈。虽然最近爆出Twitter认为客户端过多的新闻，但相信这只是前进路上的一时迷惘，Twitter很快就会重新回到正确的路上的。

所有的互联网公司都会捱过冰川世纪，成功地进入下一个时代吗？答案显然是否定的，那么，什么样的公司会成为灭绝的恐龙？先看看恐龙的特征，体形庞大，无所不能，同时消耗大量的资源。看似无可匹敌的庞然大物，在外部环境发生骤然变化时，无法获得足够多的资源而快速灭绝了，反而是那些相对弱小的动物熬过了漫漫长夜。

生物界的自然法则同样适用于互联网领域，某些公司利用充足的资源在所有领域遏制竞争对手，虽然依赖强大的用户群和充足的现金流，他们可以赢得任何一场战役的胜利。但是，他们缺少创新能力，模仿是唯一的产品发展渠道。当所有创新公司都在计划阶段首先考虑绕开这家公司时，这家公司的创新能力在逐渐萎缩。更可怕的是，当这家公司试图进入所有领域时，他们不在乎单个产品是否赚钱，维护大量的不赚钱产品会消耗大量社会资源。而且这些不赚钱产品缺少正常的淘汰机制，反而会加剧整个公司的机构膨胀和决策缓慢。

退出桌面，是目前互联网那个巨头转型到移动互联网时代的生死劫。在过去十年中，那个巨头的策略是占领桌面，用户所需要的每一种功能都可以在这家公司的客户端中找到，所以，用户就无法离开这家公司所提供的服务。而到了移动互联网时代，随着智能手机、平板电脑平台越来越多，想要抓住每个最终用户，就必须支持每一个移动平台，开发的难度和资源消耗是以倍数增长的。退出桌面、提供开发式平台，成了唯一的选择，但是上一个十年中种下的恶果，是否会成为下一个十年中的原罪？

移动互联网的开发者需要掌握用户需求、并作出快速响应，根据市场变化及时调整产品策略。小团队在这方面做得永远比大公司要优秀，他们所缺乏的是强大的后台支持系统。于是，一些大公司会将各种服务以开放平台的形式来提供，比如身份验证、手机支付、LBS、手机广告等。而小团队和个人开发者会调用各种服务，来完成各种充满创意的移动应用。而最终用户是通过这些应用来获取各种移动互联网时代的服务。

所以，我们用下面三种角色来定义：

服务提供商（Service Provider）：有一定规模的大公司，提供各种在线服务，定义在线服务标准接口；

内容提供商（Content Provider）：小团队及个人开发者，调用在线服务，来实现各种移动应用和内容信息，将直接面对最终用户；

最终用户（End User）：通过应用来访问各种在线服务，并通过购买应用、点击广告的形式来支持整个产业链。

不过，千万不要以为服务提供商必须是大公司，很多的在线服务会由小公司或个人提供，比如提供自己家周围500米的天气预报服务、提供甲骨文与汉字对照服务。但由于他们无力定义在线服务的标准，并且没有足够资源推广他们的在线服务。通过某种形式，接入到几家有影响力的在线服务提供商的系统中，并通过标准接口为应用程序提供在线服务。目前，这种服务接入架构还没有出现，相信随着云计算平台的完善，这种在线服务接入方式很快会出现。

<图：Service + Client结构图>

我们用了太多篇幅来勾勒移动互联网的框架，接下来，让我们来看看Game Center在线服务吧。

移动互联网的第二座金矿

如果说App Store是移动互联网时代的第一座金矿，现在我们试着寻找第二座金矿，LBS、手机支付、手机广告，都是第二座金矿的理想选择，我们选择的是一个相对生僻的领域——Game Center。我们姑且将“移动游戏社交平台”称之为Game Center吧，这是Apple的叫法，在XBox 360上叫做XBOX LIVE，在PS3上叫做PSN。这也是移动互联网的一大特色，不同平台上的同一个东西会有不同的名字。

Game Center可以分为两类，一种是由操作系统厂商提供的，比如iPhone的Game Center，Windows Phone 7上的XBOX LIVE；另一种是第三方提供的，比如iPhone、Android上的OpenFeint、ScoreLoop、Plus+，Windows Phone 7上的OpenXLive。

说到Game Center的起源，也可以分为两类：来自家用游戏机，比如XBOX LIVE和PSN，他们定义了Game Center的基本要素，比如用户ID、头像(或Avatar)、积分榜和游戏成就等；智能手机原生平台，这个就必须谈到大名鼎鼎的OpenFeint了。

OpenFeint的作者是iPhone游戏的早期开发者之一，开发了一款叫做Aurora Feint的游戏，其中包含了在线积分榜和游戏成就系统。一些iPhone的游戏开发者开始在自己的游戏里使用该系统，以至于Aurora Feint的开发者发现这个积分系统比游戏更加流行，便将积分榜和成就系统拿出来形成单独的产品，于是就形成了著名的OpenFeint。

可以说，OpenFeint的发展历史也恰好勾勒出Game Center的特点。由于智能手机的游戏开发者都是小团队或个人开发者，开发积分系统虽然没有什么难度，但是服务器的维护、代码的后期管理，这些工作量就已经超过了游戏开发本身。出于经济学的考虑，开发者如果单独维护积分系统，还不如再去开发一个新的游戏。于是，较早起步的开发者会共享自己的服务器资源、积分系统代码，而随着游戏数量的快速攀升，维护积分系统本身的收益，却超越了开发游戏本身。社会分工更加明确，使得移动游戏开发形成了分工更为明晰的生态系统。

在家用游戏机上，XBOX LIVE和PSN也是最火热和最赚钱的在线服务，但是一直处于从属地位。原因大概与游戏机上的游戏多为大制作，使得玩家更加关注游戏本身，而积分榜、成就系统的界面也会根据游戏进行定制，使得用户不易察觉背后的积分、成就系统。

真正赋予Game Center实际意义的还是智能手机平台，玩家在家用机平台上更多是扮演一个虚拟的角色，联机对战功能也是由游戏自身提供的。而在手机游戏中，玩家会更接近真实的自己，增加了位置定位功能和SNS交互功能之后，手机游戏会向SNS游戏的方向发展，增加更多真实好友间的互动特性。

目前Game Center还处于初始阶段，单机游戏仍然是手机游戏的主流。手机游戏同样会经历PC游戏的发展历程，从单机游戏、到局域网对战、再到广域网对战，最后是多人实时在线游戏。当然，由于手机游戏，是在人们零散的时间中消遣娱乐的方式，所以弱连接的交互游戏，会比强连接的多人游戏有更大的发展空间，但从单机到多人的发展趋势是变不了的，因为人类是群体动物，沟通与交流是他们的本能之一。

从上面的介绍中，我们可以发现，Game Center是一个与游戏数量紧密相关的在线服务。如果没有足够多的游戏，Game Center的服务器开销、维护成本、开发资源的支出，使Game Center处于入不敷出的状态。最可怕的是，如果没有吸引到足够多的用户，就无法吸引更多的开发者使用该服务，会使得用户资源与游戏资源处于逐渐枯竭的状态。只有当游戏数量超过阀值之后，新增的游戏所消耗的服务器资源趋近于零，于是，又一个经典的长尾理论场景出现了，可以提供无数个的在线游戏，再冷门的游戏也会有自己忠实的拥趸。当游戏数量达到一定程度后，热门游戏会逐渐浮出水面，几个热门游戏会为Game Center提供大量的注册用户，而注册用户数量恰好是Game Center服务的最好推手，很多新的游戏形式会随之出现。

我不知道这个阀值是多少，但是OpenFeint在2010年9月的数据是1000多款游戏、130万用户，平均每个游戏1300个用户。当然，游戏与玩家的分布绝对不是平均的，前几位的游戏肯定贡献了大量的用户。

未来的两个方向

目前Game Center还处于初始阶段，到目前为止，没有任何一家第三方的Game Center盈利，成绩最好的OpenFeint也只是完成了第二轮融资。未来的发展方向是什么，如何盈利，这些问题困扰着每一个在黑暗中前行的创业者。

XBOX LIVE和PSN采用的是订阅收费的机制，这必须依赖于强大的平台支持，以及这个平台上拥有足够多的专属游戏，很多人成为XBOX LIVE的金会员，是因为XBOX 360上的游戏足够吸引人。

而在手机游戏的世界中，向最终用户收费的订阅模式显然不合适，无论是原生平台，还是第三方平台，收费就意味着要与游戏开发者达成分成协议，因为Game Center服务是嵌入到游戏中的。手机操作系统提供商对于游戏开发者的控制，显然没有家用游戏机领域那么强势。这就是手机与家用游戏机最大的不同，游戏机靠的是质量，而手机游戏靠的是数量。

那么，在Game Center上我们是否可以复制App Store的成功呢？还是先来看看各自的优缺点吧。

· App Store

模式简单，能在较短时间内带来大量收益，必须有操作系统和开发平台的支持，否则验证过程会成为埋葬无数财富与梦想的泥潭，这也是我不看好缺少操作系统支持和支付手段第三方App Store的主要原因。缺点是，一买一卖，缺少用户黏性，无法形成有效的反馈机制。

· Game Center

能够掌握大量用户的个人信息与好友关系，可以形成有效的信息反馈，与游戏开发者的结合更为紧密，拥有较高的用户黏性，通过推荐游戏方式，有助于用户形成持续的使用习惯。缺点是没有直接的获利模式，短时间内无法形成有效且持续的现金流。

好了，Game Center如果想成为移动互联网时代的第二座金矿，那么只能扬长避短，利用自己的优势，找到合理的盈利方式，以确定下一步的发展方向。

目前我们能够看到Game Center的未来发展方向有两种：Marketplace或SNS，需要指出的是，这两者之间不是非此即彼的关系，而是侧重点各有不同而已。

· Marketplace：

我们在这里采用Marketplace的称呼，主要是泛指智能手机平台上的在线应用商店和店中店模式。这也是最明晰的一个发展方向，当你的网站拥有上千个游戏时，网站本身就会变成一个推广渠道。OpenFeint在这个方向上走的最远，OF Channel支持用户在手机上查看、浏览OpenFeint的游戏。店中店的形式可窥一斑，但这样最大的问题在于，需要和官方的Marketplace产生利益冲突，支付、下载等还需要依赖官方的Marketplace。在Android这种对第三方Marketplace控制不严的操作系统上，可能问题不大，换到iPhone上可能就存在一定的问题了。

“One Touch iPromote”兼具了Marketplace和SNS的部分功能，但是目的还是为了推广应用，而非为最终用户提供一个SNS的交互平台。

· SNS：

Game Center是SNS Game吗？不是，Game Center是Game SNS。强调Game Center的SNS特性，也许是第三方Game Center的唯一出路。第三方Game Center大都选择支持多个手机平台，一则是开发者有向多个平台移植游戏的需求，二则，只支持某个手机平台的第三方Game Center，会面临原生Game Center的残酷绞杀。前面曾经讨论过第三方Marketplace一定败给原生Marketplace。同理，原生Game Center在自己的平台上也具有无以复加的优势，但这种优势是相对的，离开自己的平台之后，这种优势反而会变成一种劣势。不过，身边的朋友都使用一种手机的概率是微乎其微的，所以提供跨平台支持，是Game Center的必由之路。这种跨平台是无疆界的，XBOX LIVE支持Windows Phone和XBOX LIVE，这个充其量算是在自己院子里溜达了一圈，如果哪天XBOX LIVE宣布支持iPhone或Android，那才算真正的跨平台。

OpenFeint和ScoreLoop对此看得非常清楚，在稳定了iPhone的基本盘后，毅然选择了Android作为第二平台，目前的成绩还不错。不过目前的SNS交互，仍然游离于游戏之外。如果让SNS与游戏结合，也许是接下来我们要思考的问题。

未来的服务

接下来，我们试着探讨一下未来Game Center会支持的在线服务有哪些。

SNS

由于目前的手机游戏仍旧以单机版为主，增加其互联互通的特性，应该是下一步的发展重点。但是，人们用手机游戏消磨的主要是零散时间，比如开会前的几分钟，等人的时候等，且地点不固定。所以，手机游戏不会像PC游戏那样，首先演化出局域网游戏来，然后再扩展到广域网上去。所以，对于时间和及时性要求不那么高的SNS游戏会抢得先机。

SNS游戏也许会成为手机游戏的下一个热点，在这个热潮中，Game Center大有可为。因为从本质上说，Game Center就是一个带积分榜、游戏成就的用户交互系统。建立用户交互系统，是一个手机游戏开发者所不能企及的，这就需要专业的Game Center提供商为游戏开发者提供完善的用户注册、验证服务。

目前的Game Center系统仅仅将SNS看作用户登录的接入方式，还没有提供将SNS嵌入到游戏中的接口。如何定义和抽离SNS游戏中的共有元素，使其成为积分榜、游戏成就那样的标准元素，并将接口标准化，将是Game Center下一步发展的重点。

Facebook是最接近这种架构的在线服务，但是Facebook是将Web SNS游戏的服务器接入到自己的服务中去，并且开放自己的用户登录系统和消息系统。这个架构对于Web SNS游戏来说是足够好的，但是如果直接应用到手机的SNS游戏中，就意味着游戏开发者需要搭建自己的服务器，这样他们对Game Center服务的依赖度就会变低。

如何抽离共有信息和游戏信息，并将其有效地标准化、接口化，将考验未来每一个打算提供SNS服务的Game Center提供商。

另一个关键点是Avatar的标准化，XBOX LIVE在这方面走在了前边，提供了一个3D卡通编辑界面，能够设计出与玩家类似的卡通形象。游戏开发者可以通过标准接口来调用这些卡通形象，并将其应用在游戏之中。不过，目前成功嵌入Avatar的XBOX LIVE游戏并不多，可能的原因有以下几点：开发较为复杂，3D形象受到限制，Avatar与游戏的契合度不高（想象一下，在三国游戏中，忽然出现一个戴牛仔帽的人物？）。

总之，SNS Game Center缺的不是需求，缺的是标准化的接口。OpenFeint的历史教育我们说，当我们不知道怎么做的时候，说明时机还未成熟，也许手机上出现大量SNS游戏时，才是Game Center加入SNS最好时机。

Location Based Game

LBG？是的，我们讨论的是在Game Center中加入LBS功能。目前的LBS典型应用是Foursquare，通过Check-in获取徽章、赢得奖励的方式，其实已经在LBS应用中增加了游戏的元素。LBG游戏也随之出现，比如城市追逐类、大富翁类，利用玩家所在的真实位置，来进行虚拟游戏。

LBG听起来不错，但是和Game Center有什么关系？本来没有，但是放到移动设备的场景下就有关系了。游戏的主题、策划、兴趣点，是需要经常变化的，才能吸引玩家乐此不疲。在这之外，什么是不变的？定位服务、好友关系，现在是不是觉得跟Game Center有那么点关系了？

我们需要做的事情是将LBS抽离出来，封装成标准化的接口，比如发现游戏玩家的位置信息、查看好友状态、邀请好友加入游戏，然后让游戏开发者通过标准接口进行调用，实现不同题材的游戏。

似乎LBS提供商和Game Center提供商都可以做这件事，为什么非要让Game Center来做呢？优势有两点：第一，开发者熟悉了Game Center的API调用方式，会更加容易地使用Game Center所提供的API；第二，虽然加入LBS服务对于Game Center来说，也不算容易，但相比起LBS供应商要加入游戏元素来，还是要简单许多。

还有一点，LBS服务提供商本身也是应用提供商，会和游戏开发者存在竞争关系，而Game Center则和已有的LBS提供商没有任何交集。当然，免费的LBS服务也要活跃起来了，比如Google Location还有MobileMe，哦，MobileMe免费？谁说的？等等看吧。

LBG得到游戏玩家的接受，恐怕还有一段时间，个人认为，最早获得成功的LBG游戏，应该是城市探索/解谜类的游戏，穿梭在陌生的街巷之中，试图发现青砖黛瓦背后的虚拟真相，我就是名侦探……动画片看多了。

云游戏平台

我们不能将云游戏平台视为一种游戏在线服务，因为它是一种Cloud Computing Hosting。虽然Amazon、Microsoft、Google都提供了完整的云计算解决方案，他们将会统治未来十年的主流云计算领域。

但是在某些细分领域中，其他的云计算供应商仍有机会。因为通用的云计算平台可能有存在以下问题：

1，不适用于某些具体的应用场景；

2，供应商会打包卖给你许多用不着的服务；

3，为了通用性考虑，而损失了某个领域/功能上的实用性

归根到底，选择哪种云计算平台，还是开发者说了算。当然，我们在这里讨论的云计算专指PaaS，而并非IaaS。

提供一个云计算开发平台、提供云计算服务集群，听起来似乎是只有业内的领头羊才可以做的事情，但是如果加上“细分市场”这个前提条件，范围一下子就变大了。

通用领域的云计算市场肯定会由几家巨头公司来把持，但是对于某些细分市场来说，整合他们的共有需求，提供针对专门领域的云计算服务也不是不可能的。某个特定领域是否需要云计算，并不是由某个善于拍脑袋的领导决定的，而来源于这个领域的真实需求。比如，MMORPG肯定不需要云计算，因为服务器是游戏运营公司的核心资产，他们需要开发独有的服务器端应用、维护服务器，云计算减少的维护成本，不足以弥补转型所带来的开发成本上涨。如果将来他们转向云计算，那也一定是IaaS，而肯定不会是PasS。

那么手机游戏领域是否适合云计算呢？非常适合，原因是手机游戏的主力是小团队或个人开发者开发的……这个理由说了很多遍了。无力维护服务器，单独租用服务器不合算，都会成为手机游戏开发者选择云计算的理由。而通用的云计算服务，也未必适合这些开发者，尤其是当这些开发者还需要接入到公用的用户登录系统、SNS系统、游戏积分系统时，这种通用的云计算服务会让用户的自定义数据游离于整个游戏服务体系之外。

最佳的选择，就是由Game Center提供商来提供游戏云计算服务，我们可以将其称之为云游戏平台（Cloud Game Platform）。前面所述的游戏通用服务，身份验证、SNS、游戏积分等，由统一的Game Center平台来提供。而某些与游戏逻辑密切相关的逻辑与数据，就需要游戏开发者自己定义数据存储结构、逻辑代码，并将其部署到云游戏平台之中，由云游戏平台来解决负载均衡之类的问题。

说白了，就是让个人开发者拥有开发网络游戏的能力。而云游戏平台的收费模式，可以是按月租赁的方式，也可以是按游戏收入分成的方式。

这个构想需要跨越障碍非常之多，比如服务器的稳定性、游戏数据如何定义、开发环境是否符合游戏开发使用习惯、如何保证开发者程序的安全性。

不过，Game Center在手机网络游戏这个细分市场上，会拥有比通用云计算服务更加突出的优势，因为Game Center提供了大量基于SaaS的通用服务，而基于PaaS的自定义服务只会占用开发者非常少的开发时间，这比起使用通用的云计算服务来说，要先进很多。

云游戏平台会在三年内完成技术储备，大概五年之后，会成为手机游戏市场上的主流。

盈利模式

在说完Game Center未来的服务模式之后，我们继续下一个敏感话题——Game Center如何盈利？推广分成的模式已经在前边介绍过了，所以我们就不在这里讨论了。

我们试图按照由早及晚的方式来，排列以下的几种盈利模式：

广告是最简单的模式，也是最难的模式。这取决于你如何看待广告：如果只是接入到已有的在线广告服务中去，他无疑是最简单的盈利模式，已经有很多游戏证明，通过广告的收入甚至可以和销售软件的收入相媲美。

而如果你想自己来做一个广告发布平台的话，它又是最复杂的模式。首先要解决用户兴趣与广告之间的匹配问题，屏蔽竞争对手广告，建立广告供应商体系。当然这一切都与最终用户的数量密切相关。

由于广告嵌入在游戏之中，所以还要和开发者就分成比例达成一致，而开发者还可以选择成熟的广告供应商。由于和Game Center的核心业务缺乏交集，想成为独立的广告供应商，对于Game Center来说是不能承受之轻。

当用户达到万级规模时，就可以通过嵌入广告的方式来尝试盈利了，但自己成为广告供应商的时机，就不是我能够揣测的了。

道具

还是回到与游戏相关的领域吧，MMORPG已经为我们诠释了完美的收费模式，尤其是中国的网络游戏运营商创造“免费游戏、收费道具”的方式。

收费道具，仍旧是手机游戏中尚未充分开发的一个新领域。在MMOPRG中，收费道具主要是为了与他人PK时成为杀人利器，从而更好的保护自己的虚拟生命及财产，当然收费道具也兼具了显摆的功能。限量版、绝版道具可以买到一个天价，显摆是一个很好的理由。

可是，我们要考虑手机游戏的现状：单机版为主、SNS游戏初露端倪。在缺少众人围观的网络世界中，道具似乎无法卖到一个天价。但是，工具类道具和成就类道具，仍旧可以占得一席之地。

· 工具类道具

指的是能够帮助玩家节省游戏时间、直接通关、避免危险的辅助类道具。那些偏好使用辅助工具的玩家可以先使用虚拟货币购买道具，使之形成使用道具的习惯，通过游戏数值分析，当玩家面临困难挑战时，使用虚拟货币购买的道具不足以帮其完成任务，促使其购买虚拟货币，再使用虚拟货币购买道具。

· 成就类道具

指的是资深玩家可以通过某些困难关卡获得的随身携带的道具，比如运动类游戏中的护腕、项链等，还能够显示在玩家的个人信息页面中。成就类道具，可以说是一种可以随身携带的游戏成就。

资深玩家可以通过卖掉这些道具换取虚拟货币，普通玩家也可以通过购买来获取这些道具。

也许还有其他形式的道具，慢慢补充吧。这里就涉及到一个关键点了：道具商店。之前游戏的道具商店都是由开发者自己掌控，说白了，就是把游戏里赚到的虚拟金钱转换成虚拟道具，只是游戏的形式之一，并不具有MMORPG中的那种价值体系。

但是，如果把道具商店抽象出来，变成与积分榜、游戏成就的独立体系行不行呢？开发者通过道具商店来定义道具属性、价格，当玩家购买道具时，支付虚拟货币给道具商店，商店与开发者按一定比例进行分成，然后开发者可以按一定汇率将虚拟货币兑换成真实货币，变成真实的收入。

呵呵，一切听起来都很完美是不是？道具商店有可能成为下一个Marketplace，但首先要解决一进一出的问题：进，指的是用户的支付，出，指的是道具商店向开发者支付报酬的渠道。还有虚拟货币如何保值的问题，还是留到后边再讨论吧。

游戏关卡

目前在iPhone中已经支持了这种方式，不过也引起了正当性的争议。对于诈骗类的收费方式，我们在这里就不做讨论了，只是想寻找另一种合理的游戏内付费方式，比如关卡。

网络文学的收费模式通常是这样，由作家先写几十章出来，供用户免费阅读，当用户如痴如醉之时，小说宣布开始收费，为了能够看到最新的章节，很多人开始付费，不愿意付费的人可能要等一段时间。

这个收费模式同样适用于手机游戏之中，首先提供免费游戏，游戏分为不同的关卡，当用户玩到上瘾时，后边的关卡开始收费。要知道，游戏的吸引力要远远大于小说。这样做的另外一个好处时，开发者会专注于提高游戏品质和可玩性，而不会把心思放到另外一个坑蒙拐骗的方式上去。

游戏关卡的真正挑战是来自于技术层面，目前，所有封闭式的智能手机系统都不允许应用下载可执行文件，所以，在游戏内下载新关卡的路就被阻塞住了。

解决方法有下面几种，不过各有局限性：

· 将不同关卡分成单独的游戏：

这种方式可以解决新关卡下载的问题，还可以利用内置Marketplace的支付功能。缺点是打断用户的游戏进程，当用户忙完下载和支付之后，可能也没有兴趣玩下一个关卡了。游戏关卡是一种冲动消费，采用游戏内付费的方式，仍旧是最佳选择。

· 从服务器端获取逻辑：

我们可以将关卡逻辑放到服务器端，当确定用户付费之后，从服务器端下载新关卡的逻辑。这样做的好处是不打断游戏进程，缺点是必须将所有关卡的资源放置到游戏之中，无法实现真正的实时更新，容易被破解。

当然，这种收费模式还要依赖于出色的游戏关卡设计，如果设计出的关卡不吸引人，那么也无法获取更多的收益。

虚拟货币/支付体系

虚拟货币不是一种盈利模式，但缺少虚拟货币的话，盈利模式就无从谈起。采用虚拟货币进行支付，已经成为各种游戏的通用方式了。虚拟货币的好处很多，主要的有：

1，缩短用户的支付环节：

当用户处于冲动消费的状态下时，支付环节越长，放弃的可能性就越大，而且无助于提高游戏体验。

2，利用币值差异使用户产生错觉：

我们可以人为制造币值差异，使得用户无法将虚拟货币与真实货币的价值联系起来，让他们产生富可敌国的印象，有助于增加他们的消费。

3，使用户忽略购买行为：

实际上，用户使用真实货币购买虚拟货币是一种购买行为，而用户会认为这是一种兑换行为，他们仍旧持有等价值的虚拟货币。

如果在Game Center中推行虚拟货币，所面临的挑战也是空前的。即使是MMORPG游戏中，虚拟货币也只能在某个游戏中流通，而Game Center的虚拟货币要在整个虚拟世界中流通，而构成这个世界的基本元素——游戏，是由不同开发者开发的。如何平衡每个开发者之间的利益，使得不会产生“价格谷地”，使每个游戏开发者的利益不会受到别人的损害。

另外，如何保证Game Center中虚拟货币的币值稳定。这些工作加起来，与一个中小国家央行的责任也相差无几了。

在考虑清楚这些问题之前，我只能送一句话给这些“虚拟央行”的行长们——“像爱惜你的眼睛一样，爱惜你的虚拟货币”。

虚拟货币不是一个封闭的体系，有进有出。用户支付实际货币来购买虚拟货币，是虚拟货币的入口；而与开发者的分成、固定资产、人员成本，都可以视为虚拟货币的出口。而虚拟货币的出入口恰好就是支付体系的职责范围。

支付体系，似乎每一个在线服务都需要这样的一套体系，但是真正能够适合全球、并且让最终用户、开发者都能够舒服使用的支付体系，其实没有多少。iTunes算是最为成功的一个支付体系了，但是在面对全球的税务体系、银行体系时，iTunes仍旧有很多照顾不到的地方。

所以说，支付体系决定了虚拟货币，虚拟货币决定了以上的盈利模式。如果没有这两点的支撑，一切的盈利模式都是奢谈。

写到最后

综上所述，游戏基础服务（积分榜、游戏成就）、Social Network、Location-Based Service和虚拟货币/支付/广告系统，构成了Game Center的四大公共服务平台，而云游戏平台，则是Custom Service Hosting，用于满足游戏开发者在云端的一些个性化需求。这一切构成了一个完整的Game Center服务体系。

游戏开发者通过标准的API来查询、调用各种由Game Center提供的在线服务，而Game Center更像是一个Cloud Service Proxy，除了Game Center本身提供的服务之外，还需要将其他服务进行重新的Mash-up使得开发者可以通过单一的API接口进行调用，当然对于接入的第三方在线服务，Game Center也有必要定义一套相应的接口。

<图：Game Center Ecosystem>

十年之后，当我们回望今天时，也许才能够看清这幅图的全貌。未来十年，也许会有许多的在线服务兴起，有更多在线服务退出市场。但是，云+端的体系，是未来十年的大框架、大趋势，做技术的人不是要创造一个趋势，而是顺应趋势、顺流而下，寻找属于自己的那一片天地。

好了，我的朋友，以上这些，就是我对移动互联网第二座金矿——Game Center的勘探报告。我无法确定下一座金矿在哪里，只是试图将自己对移动互联网的理解变成现实。几个月以来，我们看了很多、想了很多、做了很多，深切地感触到——知易行难。哪怕是最简单的事情，在旷野中也会变得复杂无比。我们不知道自己能走多远，但我们的尝试却充满意义，哪怕失败，却不愿错过。

南加州沙漠里的风沙很大，你们这些在玻璃房子里住惯的人要做好准备。

致四个月前的自己！

本文链接