怎樣快速製作一個圖形化的邏輯編輯器？

01-06

遊戲製作的時候經常要給策劃開發各種編輯器，請問有沒有什麼框架可以快速構建這類編輯器，避免重複造輪子，例如AI編輯器，劇情編輯器等等
個人現在在unity3D上面做開發
加一些補充，其實我覺得真正理想的工作狀態是技術可以專註於遊戲底層框架的實現，策劃們則可以最大尺度地掌握遊戲的業務邏輯，第二點需要策划動手編程當然不太現實。

但是~~~
我曾經在一個公開課上看到過這樣一個編程軟體Scratch
還有Mac上人見人愛的機器人
如果功能足夠專一的話，編程是可以完全圖形化的！實際上這就是一個編輯器。我們完全可以把遊戲裡面的業務邏輯抽象出來實現一個類似的東西。設計人員只需要會使用這樣的軟體，就可以編寫例如任務、AI、劇情這一類業務的邏輯。看起來還是很cool的~
當然這只是一個想法。。那麼問題來了，這個想法可行嗎，可行的話有什麼框架可以實現起來容易一點嗎？

遊戲開發里，編輯器是個大坑，能不碰盡量不碰，

有現成的寧可用現成的，比如有遊戲用 Excel ，你程序跑一下excel演示下效果就得了。

關鍵是你沒法控制這個編輯器有多少個緯度，而 Scratch 這樣的事先就確定好了：什麼可以編輯，怎樣編輯，什麼不能編輯。確定好這三個問題後，他們再一組人上去設計他們的編輯器。

你去可以先問一下問問你的策劃們，他們想的清楚這三個問題么？這麼高階的邏輯抽象，身邊尚無可以參考模仿的時候，對策劃是一個比較大的挑戰，即便在你的幫助下花了好幾天給了你個方案，你覺得能用多長時間不加新的緯度呢？半年？三個月？

如果策劃邏輯足夠強，直接告訴你，1，2，3，4，5，並且以後也不會改，那好，恭喜你，你可以做得出來；或者你足夠強勢和聰明，告訴他們，只能編輯 1，2，3，4，5，以後你們的需求但凡超過這個範圍都沒轍（看你心情好壞），那也可以。

還有編輯器常見的各種redo/undo，單選/多選，複製/粘貼，UI，多條目共同編輯，交互，文件序列化反序列化，你會發現要搞這事情，耗時耗力超預期。所以，

苦海無涯，回頭是岸。

先找找有沒有開源的，盡量在上面復用，比如 Tiled Map Editor 就被很多遊戲用來做地圖。找不到的話，能不能用 Excel 來做呢？讓策劃按照規則簡單填寫些東西，給點模版，然後你寫個程序來跑結果。做的好的話，大部分時候可以讓策劃填寫 excel 去，填寫不對了，遊戲跑出問題了，還能讓測試給策劃提 bug，然後每天你下班了回頭問加班的策劃，要不要一起燒烤，沒準你們的策劃會告訴你，你先去吧，我在改bug呢，哈哈哈。

當然，如果你象人家專門做編輯器的有個小團隊就做一件事情的話，當我沒說。

1、AI行為樹插件（我木有用過）

2、劇情？任務？寫好機制策劃配表吧，這個可以按照自己實際的需求寫一個圖形化的編輯器來改寫表單？這部分感覺都是根據不同遊戲來定製，不是很好抽象，所以也沒有通用的工具來處理~

題主問的是，怎樣快速製作圖形化編輯器，那麼推薦直接用 PlayMaker，詳見知乎帖：用 Playmaker 這款 Unity 插件能做成怎樣規模的遊戲？靠譜嗎？

題主真正關心的是，讓策劃們最大尺度地掌握遊戲的業務邏輯，根據我實際的圖形化編程經驗，這基本做不到，理由：

從工作量上來說，策劃沒有精力慢慢的去拖控制項，也沒有腦力去 debug。
從技能點上來說，這種級別的通用圖形化編程，還是需要使用者具備編程思維和邏輯思考能力的。
從企業用人的角度來說，圖形化編程會大大提高培訓和招聘成本。
最根本的原因在於，圖形化編程的表達能力、邏輯復用能力，和團隊協作能力，弱於純代碼不是一點半點，因此不適合大型遊戲項目的開發。

我認為大部分零零碎碎的業務邏輯，還是應該程序員自己來。至於常見的邏輯，可以做一些模板讓策劃套。對於複雜的邏輯，可以做點配置小工具，讓策劃玩玩數據驅動。只有非常罕見的需求，才需要讓策划動用圖形化編程（行為樹、狀態機啥的）。可參考我的另一個回答：怎麼理解遊戲開發中的數據驅動？

如果只是您題圖裡面那個，可以直接集成Blockly，完全基於HTML5+JS

如果要做成連線圖這類的，我之前WPF做過一套，有商業控制項可用，HTML5+JS這類控制項就更多了。

不過想提醒一下題主，我之前WPF那個，斷斷續續做了大概半年多的時間才初步成型、一年多的時間才基本可用，兩年多的時間直到我後來離開項目也磕磕絆絆，還有許多一開始的設想和功能沒有實現。

所以快速製作這個實在很難講，因為我做這套系統花的時間確實是比較長，雖然中間牽扯了其他的開發業務，但是仍然感覺到這不是一個很容易的工作，粗略列舉了一些我自己遇到的問題，希望對題主能有所幫助。

當然，首先，個人水平有限是一個方面，重大系統設計決策時犯過一些錯誤，比如自己做了套解釋器，而沒有一開始強推引入其他腳本，技術選型上選擇了WPF而不是HTML5+JS，不過做的那會兒大概是12年，前面那個是整個項目的客觀情況限制不得已為之，後面那個則是當時確實技術嗅覺不夠，找到一個GoWPF試了試可以用所以就用了，結果幾乎沒人能接，WPF在國內遊戲圈還是小眾了點。還有一個方面是當時用的引擎是CE，不支持反射，為此幾乎重頭做了一套反射系統，這些都浪費了不少時間。

另外一個方面就是對業務邏輯的抽象和歸納過程中有許多細節問題，這些細節問題可能遠比單純做一套圖形界面、連帶支持Ctrl-Z、Ctrl-C、Ctrl-V要複雜很多。就先說CtrlC、V、Z，這幾個問題可能做的時候，如果一開始沒做過類似系統的就能卡不少時間。然後如何持久化，是分散持久化還是整合持久化，如何保證多人開發時各自的版本最後能夠統一，而且還得跟當時他的數據環境能夠統一起來？（策劃操作，最忌諱的就是數據和功能版本不一致，他連他個人資料庫，用的是你新的功能腳本，這往往得出事兒，怎麼能把這個問題解決掉？或者一開始就先警告？）

好幾年了，當時一路的過程中解決的問題都是一開始沒想到的，現在印象里也不是記得特別清楚了，準備休息，所以寫得先簡單點，抱歉了，我後面想到的話會再補充：

基本實現：

前面CVZ可能首當其衝就是得考慮的問題，然後就是New/Load/Save/SaveAs/Compile這類持久化、工作流的問題，看起來小，做起來的時候都是工作量。比如SaveLoad，要不要考慮文件版本問題？後續如果修改文件格式，沒有版本記錄該怎麼辦？節點函數調用型變化之後，重新載入過程中會不會出現異常？載入後，舊版本節點本身的連線是直接丟失掉還是先緩衝下來？語言本身的特性上的Co-routine和代理也是個大問題，Blockly也好，什麼的也罷，這個東西都不會是原生提供的，都需要自己想辦法體現出這些的概念來。

關於功能接入：

邏輯可以連線了，怎麼把程序各個模塊的功能用更簡單的方式接入到這套圖形系統中？最好是程序那邊做個函數加幾個Attribute描述，這邊就可以自己多出幾個節點出來，那麼這個東西要不要開發？影響舊模塊的部分要不要修掉？許多功能過於程序化，程序自己調用的時候都N個地方N種調法，public函數滿天飛，抽象度封裝度嚴重不夠，這些函數和類的流程是不是要重新修理來提供一套魯棒性強的調用型？

關於數據整合：

數據系統往往是讀資料庫的，怎麼在腳本里獲取數據的時候能跟數據系統打通？最簡單的方式是具名訪問，但這樣手誤填錯了怎麼辦？這種情況現實中很常見，腳本A維護，沒改名，數據B維護，改了下表結構，於是就出問題了。怎麼在這類情況發生時快速定位到問題源？要不要考慮？

調試系統：

調試系統要不要做？策劃拿這套圖做出來問題之後，他們自己怎麼能知道問題發生在哪裡了？如果遇到問題就來找程序，那麼做這套圖的意義很大程度上就沒有了——這在我的經歷裡面是切膚之痛，一開始第一年沒有做調試和斷點系統，結果……當然如果您集成Blockly，本身是會有一個初步的斷點調試Sample的，但是仍然需要您自己去做很多相關的工作，因為調試不簡簡單單是一個斷點就完了的。局部數據怎麼看，全局數據怎麼看，運行時數據表怎麼看，都需要工作量。調試系統我印象里自己是前後花了3個多月的時間才算搞穩定，而且還只是個初步能用的版本。

關於腳本機制：

圖腳本的運行機制如何？是直接解釋還是翻譯為其它目標腳本代碼？自己做解釋器，那有的做的，我當時選的就是這條路，是因為當時已經決定了最後是生成目標C++代碼，解釋器就是個臨時搞出來，然後方便自己做調試器的選擇。如果是要翻譯為目標腳本代碼、則需要看本身項目腳本的引入情況。沒有一個有效的腳本系統的情況下，首先得先去做一套腳本系統。有腳本系統的情況下，就牽扯到圖本身翻譯為腳本語句的問題。Blockly這種還好，有Samples幫你做，而且本質上這就是一個序列式的圖表化。但是如果是那種完全無限制的連通圖，像UE4的Blueprint這種的，那麼節點環路時的代碼如何生成？（一不小心就是個死循環和大量廢代碼，或者大量function）。Latent（Co-routine）節點要不要有？有該怎麼去生成代碼？（一般是Functor）策劃連的代碼性能出問題了該怎麼處理、怎麼定位？

關於邏輯和同步性：

同步性該怎麼抽象？我沒有太好的答案，因為我當時的做法挺混蛋的，這個事兒我也交給策划了，（當然，後面看UE4的藍圖也是一個樣，稍微有那麼點感覺自己好像也不是那麼笨：P）。但是這個說實話，並不是很棒的方案，策劃用不好的情況下帶來的問題要比解決的問題多，到最後程序得去做同步圖，那意義就不大了。當時我其實構想了一些新思路，但是推想過程中就有很多問題，強調通用性的話是沒法做的，基於項目，釘死一系列假設，理論上是可以把同步過程也收束住的，但是代價就是不能那麼靈活了，而且以後換一類項目這個工具都需要重新翻新。

關於項目和團隊：

最後還有個問題：策劃為什麼要用？怎麼推廣？Help怎麼做？Sample怎麼做？因為不同項目團隊，由於構成不同、做的東西也不同，可能做事的方式和方法已經形成定勢，或者各有各的勢力範圍，推廣這個東西是一個講政治的事情，有些人會認同，有些人會反對，由此導致的一系列的問題怎麼解決，策劃用這套東西做出來的東西出了問題，最後是誰的責任？如果是策劃的責任，那麼從策劃的角度來講，為什麼要接這個工作？會給他帶來什麼足以讓他去承擔風險的利益？這些雖然可能做的時候不需要考慮，但是推廣的時候可能很難避開這些問題。因此導致團隊內部的矛盾和風波，在多數情況下可能會得不償失，而使用這套體系要重新磨合團隊，這個磨合期大概要多久？從小的方面來說，業務邏輯從大到小有很多很多部分，表現型邏輯這按理說不應該是傳統策劃的事情，而應該是動作和特效的工作，單純遊戲機制的話則遠不需要那麼複雜，UE4有藍圖，Unity也有一套類似插件（我忘了名字了），現有的框架是否已經足夠完成業務？

（2017-6-7補充兩句）關於這個，我的感覺是一般策劃主管、系統設計師並不會太推崇這個東西，因為他們業務過程中實際上需要聚焦的重點並不在這些地方。具體某個模塊，特別是表現模塊、技能設計師、關卡設計師這種機制-表現混合方面的設計師則會比較願意用，畢竟這比去看程序大爺的眼色要好很多。對於後者，問題是是否真的有必要使用圖系統，還是說簡單封裝的Lua腳本就可以做到？這兩個的開發不在一個量級上。

如果您需要現成的參考的話，UE4裡面有一套Blueprint系統是有代碼的，它的調試、數據打通、包括Native代碼生成這些Feature都是做的比較完善的，可以參考一下結構設計（雖然個人不完全認同它全部的設計，但是作為一個完整系統，這個的參考價值是很高的）。HTML5的連線圖系統很多，一部分也可以F12扒代碼學流程。

如果您還在選型，我強烈建議您基於Blockly來做選型，而不要考慮連線圖這種，連線圖看起來很好，但它引入的問題比它看起來能解決的問題要大得多。而且策劃，全功能交予本身其實也是有問題的，一般來說用圖都多是用一些抽象度較高的功能，這種情況下，連線圖所提供的高靈活性其實是蠻雞肋的，絕大多數情況下用不到。而典型的Co-routine機制，比如Wait-for總共也就那麼幾種，用到的地方也不會很多，對應做一些特殊節點來處理就好。大部分情況下策劃只需要處理好一些簡單介面的調用序列、以及讀寫數據就已經足以完成絕大多數他們需要的東西了——可以參考War3編輯器，基本都是簡單序列+數據讀寫，足夠做出豐富的功能了。

但即便如此，打通數據、提供調試功能、以及對項目組的一系列深遠影響，可能都會在鋪開的過程中慢慢體現出來。個人感覺，一旦開始這個業務，很可能需要的時間是來自於後續的一系列團隊反饋的實際問題。

因為畢竟從開始做的那一刻起，可能我們的定位已經變了，從一個遊戲項目的開發者變成了一個遊戲工具服務的提供者，這一點我也是直到最後才意識到，對於遊戲工具服務要考慮的一系列問題，都需要考慮，都需要解決，而這跟搞業務其實是有很大不同的！

我雖然做過這麼一套東西，團隊對我也沒有指責和太多不滿，但是，我現在內心深處充滿了深深的悔恨和愧疚，一定程度上可以說這樣的一次冒險，是我理想主義、不成熟和輕狂的表現！雖然做的過程中把客戶端伺服器的介面體系、類體系重新捋了一遍，項目組據說在後續的使用過程中，在技能設計和boss戰上也因此可以由策劃自己做出來一些玩法。但是，很可能我對項目帶去的問題，比解決的問題要多，當時如果能選擇更保守一些的方案，比如類似War3編輯器這樣的方案，也許最後的結果能比現在會好很多很多。

就像Behavior Tree，它是AI的一個比較新的方案，看起來它也能解放策劃的生產力，但它並不適用於所有的項目類型、同樣不適用於所有的項目組織形態，比如那種全遊戲只需要一類AI吃遍天下的，這種基本不需要那麼繁重的試驗任務，設計上也有很明確的思路，只要策劃總結思路出來，程序或者腳本將其實現出來就可以了，上BT反而是捨近求遠。所以同樣是BT技術，有的團隊能用好，有的團隊用就儘是災難，還不如最後回到傳統的AI狀態機體系。同樣的道理，我不是說類似UE4的Blueprint這套體系沒有用，我只是想說，這套系統非常適合原型期小團隊快速出原型。一個不基於原型開發來組織的團隊形態，是根本不可能調度好這種圖系統的，就跟你程序需要一個核心架構設計，所有類結構都只能從這個核心架構設計思路向外延展的道理一樣。不基於原型開發來的組織形態，一開始堆就是幾十上百人，核心圖、外圍圖很容易就做亂套了，對於這樣的團隊形態，反而看起來笨拙的程序堆功能、策劃寫文檔是最穩態的結構。換句話說，為了靈活來做了一套工具，但團隊組織上根本就不容許這樣的靈活，那麼這個靈活帶來的唯一作用就只是破壞。

此外，圖系統真正的優勢，和讓策划去寫腳本、調數據表的道理是一樣的，要同時打通跟其它各個工作流之間的關係才能體現出來。在圖開發的過程中，可以有效地指向資源、指向動畫和特效、引用數據、進行數據監測和流程調試、且對於可能的錯誤有所預判，才能體現出它的真正優勢。而工作量和設計上恐怖的地方恰恰在這裡。UE4的藍圖為什麼推薦，恰恰是它同時已經打通了跟動畫、特效、場景等一系列外圍系統的通道，如果它能恢復到UE3當年Atlas的水準，那它將更加恐怖地能夠勝任大規模MMORPG的原型設計。原型期前面說了，而一旦脫離原型期，進入到資源和數據的鋪量階段，個人感覺這個時候寧可遊戲的核心邏輯體系、無論是圖做的還是代碼做的，都不要發生大的變動較好。這時候的調整更多發生在外圍邏輯、拓展邏輯和表現力邏輯上，用圖的重點恰恰是在這幾個工作流部分，但這部分如果用腳本的話，同樣很輕量，學習成本同樣會很低，策劃連寫個PlaySound，Delay，PlayAnimation 這種序列都學不會？真學不會，給他們做個讀表、根據表來調這個那個的，整體成本也要比做一套這麼老大的系統要簡單很多啊！

國內的開發團隊少有嚴格意義上那種策劃先行的原型開發的流程，特別是Unity開發團隊就更是如此了，這種情況下，我個人感覺還是得結合自己項目團隊和項目的實際來決定技術選型，先針對小系統去做小的工具，慢慢滾出一套大系統來，可能會比我當時激進的那條路要更穩一些。

當然，以上所有這些，也許只是一個老兵畏畏縮縮、沒有衝勁、混吃等死的表現。到底怎麼樣，我相信其它人一定有比我更聰明的方法來更好地解決這些問題，或者規避掉這些問題。無論如何，實踐是檢驗真理的唯一標準。個人惟願題主在項目中推進這套選型之前，能先自己玩一陣子，介紹給朋友玩一陣子，或者先去玩玩UE4的藍圖體系，再認真考慮考慮再做決定。

無論如何，祝題主好運！

我經常用.net下的winform，非常方便，你甚至不需要教程，而且可以用c#，和unity重合，不需要學別的語言了

關鍵字：行為樹。詳情似乎在《遊戲人工智慧編程案例精粹》 中有介紹。

以其英文名BehaviorTree為關鍵字在Unity和UE的資源商店裡搜索，應該能搜到不少可視化工具。

UE自帶的藍圖，也是類似的東西。

可視化行為樹工具，Unity上用的人最多的是PlayMaker，個人認為，太過重度太過低效，能把它用明白的人，必然有足夠的代碼架構能力與學習能力，不如直接寫腳本。僅僅是看起來很強大。

行為樹編輯器這東西，應當是開發的輔助，用以提升編碼效率，而非用於編碼的替代。PlayMaker就是走了歪路。

我曾經有兩個項目用過NodeCanvas，它除了行為樹外還自帶可視化狀態機和對話樹。由於當時是早期版本的緣故，問題成噸，沒少給作者寫信。現在應該進化了吧。

國內有個叫魚鬆momo的知名Unity用戶，放出過一款「自製BehaviorTree插件」。其實就是扒的NodeCanvas的代碼。

Unity上其他行為樹工具，2016年5月之前的我都看過，都還不如NodeCanvas。後來出的如果有更好的，請留言告訴我。

UE上，藍圖很好。絕大多數指責藍圖坑多的人，基本都是因為他們將這東西徹底當成編碼的替代來使用了。

行為樹編輯器，對使用者的程序架構能力的要求一點也不低。然而弔詭的是，程序架構能力高的人，其編碼能力往往也很高，同樣，編碼能力低的人程序架構能力往往也很低。但這種可視化工具最為吸引的卻又是不怎麼懂編碼的人。

於是，藍圖並沒有他們講的那麼坑。

最好自己開發，有利於將來把核心代碼應用到其他項目。當這些代碼逐漸累積起來之後，到了新的項目就不用重複造輪子了。

圖形化編程和代碼編程本質是一樣的

一般策劃不會用

就算用也不放心

會編程的策劃不屑用

圖形化編程遇到複雜邏輯

簡直繞的一塌糊塗

不管是excel還是json還是xml

難道沒有發現策劃實際只是想填數據么

所以數據驅動才是王道啊

就算做圖形編輯器

也應該做數據編輯器（參考星際爭霸2的數據編輯器）

曾在編程貓工作，主要工作就是造一個圖形化編程工具的輪子。

使用Blockly的UI（積木拖拽那部分）但並沒有使用Blockly推薦的jsInterpreter做解釋器，而是針對圖形化編程工具設計了一個專用的解釋器(原理類似於scratch-vm)，原因是大量的字元串處理導致性能比較差，解釋器之間的數據傳遞非常麻煩，函數的實現非常繞等等。。首先編譯器將Blockly輸出的XML編譯成"可執行"的結構(JSON 樹)，再丟到解釋器里執行。接下來篇幅會比較大佔個坑以後再補充。

至於造輪子的原因，

1) scratch2.0/3.0 其實有很多設計缺陷／歷史遺留問題

2) scratch2.0 是flash做的，移動端上無法使用，scratch3.0雖然是基於js的但開發進度緩慢，到目前都還是不可用的狀態

3) 性能問題

另外我自己也在做開源的版本，希望我在這方面的積累能促進圖形化編程工具的統一（特指應用於教育的類scratch的圖形化編程工具），大家就不用再造輪子了。

https://box.game/#219563 https://ide.codemao.cn/

難道沒有策劃告訴你，他們更喜歡用Excel么？

難道沒有策劃告訴你，下一款遊戲到底做啥還不一定呢，你的復用次數很可能就這一次么？

你做的很酷炫，很吊炸天，然後策劃會碎碎念，這貨到底特么怎麼用啊，程序員你夠了，你搞的這貨的用戶體驗完全不如Excel好啊

可以做，我也正在做。初步結果也用在了項目裡面。其實原理很簡單，實現幾個關鍵部分就完成大部分工作了

1，反射，我是用c++的，如果用其他天生支持反射的語言會更省事

2，vm，合適顆粒度的抽象vm，用來跑邏輯指令的。一定要規劃好調試介面

3，合適的對象系統，順便把序列化反序列化做了，實現一下屬性可見性，方便做同步

4，終於到ide了……有了上面的支持，你已經能用很簡單的做到對象指令編輯，存儲，調試，無非選順手的框架實現罷了。我用的是imgui

5, 同理，搞定屬性同步

6，開始填充你的小組件吧

有這套支撐，我做了一個很複雜的戰鬥系統，幾經幾個月沒添加東西了，策劃們新技能依然組合的花里胡哨

未來將嘗試涉足其他系統

其實很簡單，把編輯器看成是一個編程語言編譯器/解釋器，那麼編輯器中的每一個節點其實就是抽象語法樹（AST）中的一個節點，等於是，用戶用編輯器手工構造AST，省略了詞法分析和語法分析的過程，後面的語義分析和代碼生成（或者解釋執行）都和普通的編譯器/解釋器一樣。

目前大多數公司的做法，都是使用類似於 Unreal Engine 中藍圖（Blueprint）的方式，也是未來的發展趨勢。做法就是把需求解耦，切分成可復用的小函數，每個函數實現為一個節點，並定義輸入輸出的方式。

比這個抽象度低的，如題主所說的類似於Scratch，策劃用起來麻煩，一個邏輯功能工作量要提升很多，而且容易出BUG。況且如果策劃真的編程能力足夠，邏輯性足夠，那麼直接用腳本語言（如 Python）寫是更方便的方式。

比這個抽象度高的，靈活度較低，功能迭代，參數調整不方便，程序工作量也大幅提升。

此外，類似於藍圖的做法實際上是一個通用框架，也可以用來調材質，生成shader，美術也能受益。

每個大公司都有自己的一套編輯器，我在金山的時候見過，但那時候還小，接觸不多。在暢遊的時候沒有，但有很多人跟我一起試點做這樣的工具，四五年前的事情了，現在估計已經成型了。後來去祖龍之後，發現完美系的也有自己一套成熟完善的工具鏈

但是快速開發…我覺得你想多了

我原來也做可視化的遊戲邏輯編輯器，後來發現，策劃們的想像力太豐富了，導致我的邏輯編輯器不斷修改。

後來我強迫策劃們學python了。然後用IronPython寫了個腳本編輯器，整個世界都清靜了。

怎麼沒人提construct2? 它本身就是一個h5遊戲引擎，還是開源的。圖形化編程形式類似答主給出的例2. 但是國內相關資料比較少

可行，沒有特別現成的框架來干這件事兒。實際上何種技術都能搞，但是需要一個能繪圖的庫或者是和引擎能共享畫面展示。用c#的winform配gdi開發速度很快，如果純2d且不考慮動態預覽的話可以考慮。3d建議直接和遊戲運行的引擎用一套技術。反正還是要做大量的和遊戲內容相關的業務工作，這不是框架能幹的。

整個過程的難點在於，編輯器需求提出方(策劃或是製作人)而言，需要一個非常清晰的思路來把ta的遊戲流程切分成合理的幾個部分，在此基礎上進行抽象才有可能做出來好用的東西，「提需求」和「需求分析」部分內容的難度，及與之相關的整體架構把控（如數據和引擎的通信、腳本調用等），其實大於撤銷重做保存持久化這些純技術實現（因為在其他領域的編輯器中也有）。

例如，純事件驅動的劇情表演、主角在地圖行走觸發戰鬥、ai狀態機等，是否需要每種類型額外編輯器？如果某功能無法通過純gui操作實現，程序員如何臨時介入？

總體來說還是一個需要投入一定量資源的領域，只做一個領域的遊戲，一個季度內還是能做出來湊湊合合能用的東西的。但是做到人人都能用所有功能都內置在軟體里還是有些困難，要不也不會有那麼多遊戲廠商的內部編輯器還得藉助excel了...

利益相關：原某avg製作工具廠商程序員

1. unity上有一些圖形邏輯編輯器插件，如play maker, flow canvas, 它們基於unity編輯器擴展實現，不太需要自己考慮圖繪製，涉及以下API

BeginWindows();//立即繪製API

GUI.DragWindow //繪製可拖拽node

GUI.Window

Handles.DrawBezier //繪製node連接

EndWindows();

可以做出非常複雜的圖形效果，但重點仍然是如何映射圖形編輯和邏輯結構，這就是一個所有編輯器需要解決的通用性問題，

2. 我對此圖形化邏輯編輯器也非常感興趣，嘗試做過一個通用的（不依賴引擎擴展）的可視化邏輯編輯器，思路是，圖形生成控制流，數據流結構，VM解釋執行，然而這是純業餘的玩具，我希望有機會做成有用的東西。

1）hello world

2) 不需要一行編碼的 flappy bird，分層邏輯，上層看得很清爽

cherries,一個圖形化編程語言

題主沒見過rpg maker吧？

題主想法是好的，但畢竟編輯器開發也要佔工作量，在動工之前最好先和策劃確認好如下內容:

(個人對AI接觸比較多，拿AI系統舉例)

1. 系統的體量/複雜度

如果系統涉及的內容過於簡單，用配置表格即可完成配置的話，就不需要編輯器了(如掛機刷怪主推pvp玩法的rpg)

或者系統涉及內容複雜，但是涉及的單位數量少，或者更新頻度低(比如定期更新boss挑戰玩法的rpg/卡牌遊戲，boss的AI雖然比較複雜，但由於一期活動只推出兩三個甚至一個boss，對編輯器的需求也不大)

2.系統的側重點

如moba/fps/對戰卡牌的AI主要模擬玩家行為，AI系統需要方便地獲取遊戲內的各項數值，同時策劃可能需求根據一系列配置參數來更好地控制AI特性

而rpg的AI通常是作為關卡玩法的一部分存在，需要對基於時間和事件的觸發行為有良好支持，同時還需要多個AI單位之間建立方便的相互通知方法(如仇恨傳遞，boss戰鬥中的小怪行為等)

3.未來的系統內容規劃

如果某個系統在開發初期內容不多，但是未來版本中會加入大量內容的話，可以在系統開發時預先為編輯器留好後路，不過這個比較偏經驗向，就不展開了

以上是策劃視角的一些建議，希望對題主有幫助w

用圖形樹來做遊戲？GameMaker?

根據我的遊戲開發經驗啊。

把一個功能做出來花的功夫是1.

把一個功能做到好用沒bug是8

把一個功能做到完美是10

把一個功能做成圖形化編輯器是300

祝你好運