上周五公司年會。在一個從頭到尾我都不知道名稱的地方進行的。最有吸引力的抽獎環節中，我們小組全軍覆沒。明年繼續幻想！ 周五晚上玩了一種叫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

總結

以上是生活随笔為你收集整理的uno的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。