Silverlight 游戏开发记录（1）

做为一个很早学习Silverlight 的银光人，07年底就开始使用了Silverlight了，08年末就冒出使用Silverlight开发网络游戏的想法。很可惜，09虽然成功的转身到了web游戏开发行业，最后因为种种原因，项目使用了as3,导致最后只能去写服务端(我只会C#)。

还是as3项目的原因，开发了一半，被迫结束.人员散的散，离的离。最后进入胶着状态。

公司因为某些原因，非常需要自己的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个客户端，实际上同一时间内没有太多对象，所以，这里完全没有性能上的忧虑。

我的核心设计主要如下

代码

Console.WriteLine("脚本系统测试开始");
Console.WriteLine("新建生物");
Entity play = new Entity("玩家");
Entity guard = new Entity("城市守卫");

//加入受伤处理脚本
TestScript ts = new TestScript() { 攻 = play, 受 = guard };
guard.Hurt.AddHandler(ts);

//为城市守卫创建触发器
ScriptEvent dieEvent = guard.Events.CreateEvent("Die");
//为触发器加入死亡处理脚本
DieScript ds = new DieScript() { Et = guard };
dieEvent.AddHandler(ds);

Console.WriteLine("测试生物攻击");
guard.ByAttack(play);
guard.ByAttack(play);
guard.ByAttack(play);
guard.ByAttack(play);
guard.ByAttack(play);
Console.WriteLine("脚本系统测试结束");
Console.Read();[/code]

呵呵，很像魔兽争霸吧，额，就是模仿魔兽争霸编辑器滴。

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

还缺什么，好像还有声音，不过又不是3d游戏，声音就是播放下声音文件而已。暂时先没有设计，或者放到客户端主逻辑里设计也行。如果还缺其它关键系统，请留言指教。