uno

上周五公司年会。在一个从头到尾我都不知道名称的地方进行的。最有吸引力的抽奖环节中，我们小组全军覆没。明年继续幻想！ 周五晚上玩了一种叫UNO的纸牌游戏。和变色龙有点相似。不过有更丰富的功能牌。9个人玩到晚上3点多，实在撑不住了。 周一回到公司开始构思写一个这样flash游戏。今天终于有点眉目了，写了4千多行代码，先看看截图吧。设计就不要打击我了，一切从简！ 游戏使用的架构有点特别。flash即使服务器，又是客户端；所有计算都在客户端，然后数据在swf里面计算后，交给服务器，由服务器分发给所有连接玩家： 这里展示是一个大致的数据流向，那玩家出牌为例：玩家点击一张牌出牌，这时候并没有出牌，而是将改动作发送给服务器【2】，服务器将数据分发【3】；这个时候，主swf（主swf是整个游戏模型运作中心）接收到该数据后，将数据输入游戏模型中做运算处理【4】。处理后，该结果——真正的出一张牌，被交给服务器分发【6】。接下来就是各个swf接收到该数据，做相应处理。 这样的架构，缺点肯定是存在。首先是数据请求太繁琐。每个操作几乎都是得先发送操作请求，然后到主swf中去运行。然后才被公之于众。不过，同时又体现了一个优点——服务器架构简单！因为，此时服务器就只做一件事：接受数据并分发。其实使用这样的架构，也是由于我几乎不懂服务器端的搭建。就在周一，我尝试用用socket连php，结果无奈失败二终。最后还是使用FMS——这个游戏服务器端，只有32行代码。这个代码量，估计用任何后台语言重构都是一件简单的事。 令一个缺点就是，数据的保密性。由于游戏模型在swf中运行，这样就难免需要发送一些敏感数据。比如，当主swf关闭时，同时其整个游戏的模型也被销毁，为了游戏能照常运行，需要另外的swf重构一个model来继续运行整个游戏。这个时候就需要原先模型的运行数据。于是模型的运行数据被无情的被传递，包括当前用户手中牌列表。如果采用服务器运行游戏模型的话，就不需要了。服务器肯定是一直开着的。 自己其实还是挺喜欢这样的架构——适合做一些局域网内运行的小游戏。这次也是第一次开发纸牌类游戏。a za za~~

转载于:https://www.cnblogs.com/laan860102/archive/2009/01/16/1509232.html