想做游戏却不会入门？来看看这篇开发记录

最近有很多客户要使用我们的云服务器搭建游戏，在和客户沟通的过程中发现，如今想要自己开发游戏的人真的不少，不过也有很多人并不知道怎么入手，这里我们找到一位大神的游戏开发记录，希望能对有志于游戏开发路的你有所帮助。

公司因为某些原因，非常需要自己的mmo游戏。于是，又开始了新的项目，这回，我总算搞上Silverlight客户端了。不过，悲剧的是，公司完全没有招人计划，结果本人即要写客户端，也要写服务端。神啊....
我所知道的Silverlight开发的在运营的商业网络游戏，貌似是一款都没有，当然，有个魔兽世界在做。还有其它好几款，不过都没有正式商业运营。这不能代表Silverlight比as3差。公平的说，Silverlight略胜 as3, 长远的说，大胜 as3.大部分情况下，使用silverlight 和 as3 开发的都是2d, 或所谓 2.5d 的等角游戏，在基本效率上，2者是半斤八两，如果有人说 silverlight 快过 as3 多少多少倍，那绝对是瞎说。在我看来，as3 的优势在于市面上不少成品，设计人员比较容易找（这里指UI设计）。劣势是相对as3程序员较少，并且开发工具实在是不如vs.silverlight的优势在于，有大量的.net开发人员，这些人如果有丰富的c/s开发经验，或wpf经验，学习silverlight非常快。另外，如果团队小，人员吃紧，还可以调用客户端的去开发服务端。as3 可开发不了游戏服务器啊。当然，劣势在于设计人员非常难找，会使用Blend的人设计人员太少。下面正式说客户端。我看过魔兽世界部分代码，我比较佩服其开发人员，的确很周到和仔细，可能之前有过相关经验。但是，我认为毛病也是非常明显的，魔兽世界是一个典型的面向对象设计，重重继承，跟踪1个类到其基类，竟然继承了10多级。如果是自己开发，并自己维护，可能无所谓，如果有天自己干累了，想让别人接接手，估计那人就痛苦了。一些游戏开发书籍上，以及很多游戏，比较流行的方式是组件式设计。颇有代表性的像游戏《孢子》。组件式，故名思意，就是像积木一样组合起来。有点插件系统的性质。这种好处是显而易见的，容易修改，还容易做相关编辑器。组件设计的原理是这样的，所有客户端里的游戏对象，有1个对象id,如果这个对象可视，就为这个对象增加1个可视组件，如果可被攻击，就为这个对象增加1个攻击组件。当然，我们有1个组件管理中心来负责游戏对象的功能注册。这种设计一个无法绕过的缺点是，需要频繁的进行组件功能查询。不过，作为1个客户端，实际上同一时间内没有太多对象，所以，这里完全没有性能上的忧虑。我的核心设计主要如下 额，比较臭美的用System结尾NetWorkSystem: 网络库，其内部结构为有些臃肿，主要是我从服务端通讯模块里“扒”出来的。这个结构，要偷偷汗颜一下，大部分从某开源里学习的，内部做了一些改进。Silverlight MMO 游戏与传统的客户端游戏都是使用Socket进行通讯，通讯的过程就像用快递送东西。举个例子，你的公司如果是个游戏客户端，你是游戏里的英雄角色。如果有你的快递，会是个什么情况？------快递送东西送到前台，前台并不认识你。1。也就是说，你首先得告诉前台你是谁，那部门的，坐哪个位置，分机号多少。2。你的快递包裹到了，前台查了下人员名单，发现和你名字很像，于是打电话让你取掉。3。你获得包裹，拆开看看，发现是报销发票，于是你就送到财务去报销去了。 设计思路就是

1 2 3 4 5 6 7

/// <summary>     /// 接收消息接口，所有需要从网络接收消息的对象需要继承此接口     /// </summary>     public interface IReceive : IComponent     {         void OnNetMessageArrive(ushort MessageID, byte[] Message);     }

所有需要进行消息处理的游戏对象都继承这个接口，然后注册到网络消息投递中心，当有消息来，就会把消息投递到游戏对象。大部分游戏都是这样设计，由于从客户端的角度看来，通讯频率不高，所以这样做没什么错。但是，通常，某个对象不可能只处理1条消息，于是方法内部就搞一堆的case 来处理不同消息号的消息。其实，完全可以把功能也注册到消息投递中心。因为一般说来，某个消息号的消息只由1个固定类型的对象来处理。最后就成了快递到了，前台先看了下快递单上的代号，查了下表，发现是你的报销单，于是直接帮你送到财务去了。ObjectSystem: 前面说的组件系统，比如消息对象接口IReceive,就要继承组件接口IComponentRenderSystem: 渲染系统，Silverlight里谈不上什么渲染，实际上就是能看见的可视对象，内部有个IRender 接口组件，所有需要显示的，例如角色，地物，地图，掉落物，动画，效果，统统继承该组件。并由渲染管理器进行管理。ResourceSystem:资源系统，这个无论游戏还是其它程序都是必须的，就是负责加载和读取资源。主要需要从网络读取，从本地存储读取。所以一般的，文件路径都是相对路径。这里，我有2个接口，1个IResource 资源接口，用来实现不同的游戏资源格式。1个IResourceLoad接口，用来实现资源的加载处理。这样，可以为同一类型的资源，修改使用不同的加载方式。SceneSystem: 场景系统，主要进行游戏场景的管理。例如 处理地图的层。一般的，游戏场景都是由若干层叠加的。加载的时候默认可以逐层加载，比如先加载最下面一层，通常是背景层，然后加载地表层，地物层，拾取层，角色层。当然，你想分几层就分几层，最上面一层，也可以用于界面层。ScriptSystem:脚本系统，我没去研究过lua,也不太会C++,所以完全不知道一般网络游戏的调用脚本方法。Silverlight 可以调用javascript。个人认为，还不如直接使用C#来做脚本。javascript 直接明文可见（不知隐藏方法），并且是解释式的。另外，服务端也需要脚本，直接一套下来不省事很多。下面是脚本系统的测试图

其代码为：

 

呵呵，很像魔兽争霸吧，额，就是模仿魔兽争霸编辑器滴。WidgetSystem: 界面组件系统。这个没有考虑周全，本来是想设计成负责界面层的，后来发现貌似有点多余（想做成类似魔兽世界脚本开发界面）。其接口IWidget  继承渲染接口和消息接口。

长按二维码，关注我们

新睿云，让云服务触手可及

云主机｜云存储｜云数据库｜云网络

点击“阅读原文”参与活动