1樓：拾穗者
近幾年遊戲行業這麼火熱，技術上發展最快的是什麼，引擎。就手遊而言，國內一般2d用Cocos2dx，3D用Unity，當然還有自研引擎，Cocosdx是物件導向的思維，而Unity3d是元件思維，二者差別很大，表現在做遊戲的流程上，Cocos2d更新傳統的軟體開發，Unity3d更能突出設計。而開發遊戲過程中，設計才是最重要，設計的很大一部分體現在資料上，這就要求引擎能對資料管理更友好，更方便，Cocos2dx在這方面落後Unity3d太多，個人覺得以後遊戲引擎在資料管理方面往配置化，模組化發展，也就是DDD了。跑題了
2樓：徐波
舉個簡單例子：任務
要實現100個任務，用u3d的設計思想來做就是寫100個元件（官方設計思路，未必實用）；但用傳統設計方法，就是乙個任務系統支援一些任務型別，任務型別通過資料進行配置。所以簡單的說，資料驅動就是配置驅動。
從語言層次上來說，c#和lua一樣，對於c++來說是一種指令碼，前者更容易將資料和邏輯結合的很好，但後者如果這麼結合就是hardcoding了，因此需要將資料部分剝離，變成所謂的資料驅動。
資料驅動其實很好，程式和資料分離，但靈活度肯定沒有指令碼開的那麼高
3樓：Seeds
怎麼理解遊戲開發中的「Data-Driven Design」?簡單而言，就是在設計中,把「資料」和其處理過程分離開，
這和設計模式中的封裝變化其實是一樣的，因為資料實體總是在變化，而同一類資料的處理方式卻是不變的。
資料驅動設計又有哪些表現形式呢?在遊戲程式中，「資料驅動」包括但不限於：
各種配置表，以上答案都有提到。
各種影象資源， 比如各種貼圖動畫等。
空間狀態資訊，比如Unity3D中，乙個物件的位置狀態等等。
遊戲指令碼，比如魔獸世界外掛程式。
是不是經常和元件-實體系統搭配呢?元件-實體系統，可以說是指令碼集+實體資訊，
這二者相加才能稱為乙個可供遊戲引擎處理的資料實體
如何理解遊戲開發中的實體元件系統？
Daniel Tan 可以借鑑 ECS 的做法。以部件定義物體，而非以物體定義部件。以小鳥為例，小鳥之所以是小鳥，那是因為它有物理元件 渲染元件和鳥資訊元件。任何有這三類元件的物體都可稱為小鳥。在這種思考框架下，儲存和處理共用資訊就是處理元件組合，而不是處理物體。例如，與其把全部物體找出來再篩選有渲...
遊戲開發中，如何使用敏捷方法？
清美一刻 推薦一本書 遊戲專案管理與敏捷方法 第2版 精益敏捷的Scrum和看板，在經過適應性調整之後，在尊重專業的前提下，結合專業的優勢，可以有效幫助遊戲開發走出困境。 肥貓加菲 粗淺的個人理解。首炮打響與否，是看 beta 到全面 release 的時機和彼時的產品質量，無關乎敏捷。內部開發階段...
遊戲開發程式設計師在開發遊戲過程中是不是就已經達到了該遊戲的職業水準？
magwer 哈哈哈哈哈哈，我就經常被自己玩家虐。所以設計者肯定打不過玩家啊。這問題應該改一下，因為程式設計師只寫邏輯和演算法，一般不去設計規則的。真正設計遊戲的是策劃。題主的意思應該是，遊戲設計者是不是達到職業水準，而不是程式猿。這裡不考慮每個人反應速度和首腦協調性的差異，單說遊戲理解，設計者也是...