這主要是一年多來，個人從事erlang遊戲服開發中對一些事情的思考。
想到哪說到哪，沒有條理可言。
歡迎討論。
通常erlang遊戲服務的設計涉及到的東東包括如下：
我很好奇，erlang遊戲服都這麼做嗎？在我看來，這一切都是亂糟糟的，不是說erlang/otp系統是以應用作為構建塊的嗎？
為什麼我看不到任務應用，活動應用，公會應用、玩法應用、好友應用等等？以應用去劃分系統不是更加清晰？也許還能按需載入
資料，而不是載入整個玩家資料呢？以應用建模，興許能夠更加容易復用**呢？
再者所有東西糅雜在一起，系統的測試基本變得不可能；沒有測試也就意味著bug.
尤其常見的是玩法程序夾雜了多種玩法邏輯，通過case if pattern match 去呼叫不同的**。
通常搞好了一種玩法，也不經意導致其他玩法出現bug。（我在2個專案中都碰到了這個問題）。
我希望的遊戲服設計應該是這樣的：
也許以應用去建模，為任務構建程序顯得過於大材小用。甚至於說在玩家程序裡處理資料更加方便，避免不必要的程序間通訊消耗。
那麼我想建模成庫應用也是有好處的吧。
Elixir遊戲服設計六
defmodule table do state accept 0 準備接入玩家 state ready 1 開局準備？defdelegate fetch t,key get and update t,key,list to map defstruct config,seats,state defn...
Elixir遊戲服設計五
現在想想也沒那麼難。保證原子性，無非就是需要某個單點去完成操作。那麼選擇玩家程序去做原子性工作就可以了。比如要重置某個任務，需要花費金幣和揹包裡某個物品，那麼大概的邏輯是這樣的。在玩家程序裡 def reset task task id do task.reset need with ok gold...
Elixir遊戲服設計一
在erlang遊戲服設計總結裡，我提到我想要的遊戲服設計方法，希望以應用做為基礎構建塊。最近我在學習elixir，它有很多 方便的語法糖以及很好用的庫，能夠解決我在遊戲中開發中碰到的很多繁瑣工作。因此我決定用它來做 練手，並期望下個專案中使用它。遊戲服的設計通常涉及如下東東 我將以乙個簡單的打牌遊戲...