開發遊戲編輯器有什麼好的建議?

小弟做了個弱逼的遊戲引擎,想為這個引擎的基礎上開發個編輯器,UI系統想自己實現一遍,不求有實用價值只為學習一下,各位前輩能不能給一點建議?比如說,現在主流的實現方案,需要注意的地方等等。我之前做過一套簡單的ui系統,事件都是簡單回調,據說現在回調基於消息的什麼已經很落後了,還有什麼數據綁定啥的。


如果題主想做到最終屌方案, 就像Unity3D和虛幻那樣. 請這樣做:

1. 自己寫一套UI, UI基於即時模式, 參考Unity3D的OnGUI里UI的寫法.

2. 即時UI有一個好處, 數據和UI的綁定是簡單的, 自然的, 而不需要建立MVC架構來進行複雜的映射

3. 性能低沒關係, 你做臟更新就好

4. 盡量使用帶反射的語言來做界面, 即便使用不帶反射的語言, 例如C++, 也必須使用自動生成代碼機制保證編輯器的高自動化.

5. 如果懶得自己寫UI, 但又想用這種模式, 可以考慮web界面.

總之, 不要用傳統的UI庫, 嵌入渲染引擎來做編輯器. 最終你會發現, 自己死在數據綁定和無邊際的bug中


如果你從來沒有寫過的話,那你第一次做的時候最好跟遊戲做在一起,不然你就會發現你千辛萬苦給地圖寫了這麼多代碼結果不能在遊戲程序里用。


可以用 Fireball 編輯器的框架:

fireball-x/editor-framework · GitHub

輕鬆實現多 panel dock 的編輯器,有完備的單元測試體系。目前正在不斷擴展 UI 控制項中。

缺點是要學 Polymer,前端開發基礎差的話會有一定困難 http://www.polymer-project.org

其他 UI 編輯方式里,推薦參考 雲里.霧裡 - 雲里來.霧裡去 的 cocoslite 編輯器,在 brackets.io 的基礎上三個月做出來的。


看題主的意思是想做一個UI編輯器,這部分怎麼說呢,有一點必須要注意,就是編輯器的渲染和遊戲內的UI渲染,代碼最好用一套,就是說你要把渲染部分分離出來,脫離了遊戲也可以使用,這種編輯器的唯一要點就是所見即所得,編輯器里什麼樣子,遊戲里也應該是同一個樣子。


單說說UI部分。UI系統是個大坑,掉進去了基本就沒有時間去研究引擎的其他方面了。

給你列個提綱:

  • 1 繪圖

    • 1.1 繪製貼圖
      • 1.1.1 圖集(atlas)
      • 1.1.2 批次繪製(sprite batch)
    • 1.2 繪製文本
      • 1.2.1 點陣圖文本
      • 1.2.2 矢量文本
      • 1.2.3 文本排版(測量/換行/溢出處理)
    • 1.3 繪製(矢量)圖形
    • 1.4 透明度處理
  • 2 布局

    • 2.1 絕對布局(基於坐標的布局)
    • 2.2 相對布局(dock/anchor)
    • 2.3 集合布局(列表、表格etc.)
    • 2.4 DPI/全局縮放支持
  • 3 表現

    • 3.1 樣式(style)
    • 3.2 模版(template)
    • 3.3 主題(theme)
    • 3.4 觸發器
    • 3.5 音效
  • 4 框架

    • 4.1 窗口/模態管理
    • 4.2 彈出管理
    • 4.3 控制項樹/邏輯樹(logical tree)
    • 4.4 渲染樹/表觀樹(visual tree)
    • 4.5 臟更新(invalidation)
    • 4.6 深度管理
  • 5 交互

    • 5.1 滑鼠輸入
    • 5.2 觸摸輸入
      • 5.2.1 基本觸摸輸入(點擊/拖拽/雙擊/長按/揮動swipe)
      • 5.2.2 多點觸摸
      • 5.2.3 手勢系統
    • 5.3 搖桿輸入
    • 5.4 鍵盤輸入
      • 5.4.1 按鍵事件
      • 5.4.2 焦點管理
      • 5.4.3 鍵盤導航(上下左右tab)
      • 5.4.4 文本輸入
    • 5.5 阻擋關係
    • 5.6 事件和消息路由
    • 5.7 輸入綁定和命令系統
  • 6 動畫

    • 6.1 時鐘系統
    • 6.2 插值動畫
      • 6.2.1 easing
    • 6.3 序列幀動畫
    • 6.4 動畫控制
    • 6.5 動畫組合(composition)
  • 7 數據綁定

    • 7.1 可觀察(observable)屬性
    • 7.2 可觀察集合
    • 7.3 綁定表達式
    • 7.4 逆向和雙向綁定
  • 8 控制項抽象

    • 8.1 狀態管理
    • 8.2 控制項庫
      • 8.2.1 標籤(label)
      • 8.2.2 圖片(image)
      • 8.2.3 按鈕(button)
      • 8.2.4 文本框(textbox)
      • 8.2.5 布局面板(panels)
      • 8.2.6 捲動視圖(scroll view)
      • 8.2.7 富文本視圖(rich text)
      • 8.2.8 瀏覽器(webbrowser)
    • 8.3 用戶控制項介面
  • 9 API設計

  • 10 DSL(界面描述語言)

  • 11 編輯器

    • 11.1 可視編輯器
    • 11.2 動畫編輯器
    • 11.3 圖集編輯器

以上是一個主流偏先鋒的UI系統所需要的功能,掛一漏萬。樓主請先對照著這個提綱,看看裡面有多少是自己真正掌握的,如果陌生概念太多,還是應該以學習為主,多用用主流的UI系統(包括但不限於WPF、Flash/Scaleform、QT、NGUI),體會它們的設計和思想。這些引擎各有精巧之處,其中以WPF為集大成者。UI引擎是一個龐大的系統工程,冒然開工極易導致中途返工(很多寫過UI引擎的朋友應該都有這樣的體會,寫了若干版UI,每一版都不盡人意,但各版之間都是不可迭代的,只能推翻重寫)。如果要為自己的遊戲引擎增加UI部分,不如先抱著學習的態度整合一個開源的UI引擎。


想必是c++實現的win下引擎

最簡單辦法是使用c# winform

膠水層使用swig,倆小時搞定

再來個盜版devexpress或者dotnetbar

多窗口dock分割5分鐘搞定

propertygrid加反射,屬性編輯完全沒有問題,比c++好用到哭

隨便抽象一個actor的undoredo框架

封一個dx繪製winform控制項

句柄傳給你的引擎

實現點選拖拽旋轉

最後接上引擎和其他序列化

搞定

估計要不了一周,就可以用了

一堆推薦什麼wxpython,高大上框架的對你來說都是坑爹的,等搞明白搞熟悉好幾周過去了

山寨小項目山寨最快


你可以參看www.Phoenix3D.org編輯器的架構,如果你不打算自己寫編輯器UI的話。(實際上我還是想自己寫編輯器UI)。

要注意的很重要的一點是,你編輯控制項要能,根據所選的對象進行自動生成。

最好你要使用消息機制,這樣底層還可以通知高層,避免太多依賴。(消息機制是比MVC更好的架構)

還有,操作放在一個Lib里,編輯器只是一個殼子。暫時就想到這麼多了。


和你情況差不多

我們現在用monogame再次封裝了一個抄cocos2d的簡易引擎

配上一個自己山寨的簡易tilededitor

和輪子哥說的差不多

tiled是用引擎那一套做的

ui的話 我們用了一套簡單的ui庫 簡單到連事件分發都沒有 基本上要什麼都要自己造

我覺得題主引擎都造出來了 乾脆再造一套ui庫吧 然後用ui庫造一個maker 最後用maker做一個遊戲


照著War3地圖編輯器做就行了


三個月前我在找比較好的cocos編輯器的時候看到了這個帖子,瀏覽了一遍後繼續找cocos編輯器去了,三個月後我帶著我的BoomEditor來回答下這個問題,雖然帖子很老了,不要怪我挖墳哈!

先貼上BoomEditor的地址:

jims_c/BoomEditor - 碼雲

我先介紹下BoomEditor,然後分享下做這個編輯器的經驗(可能現在你的編輯器已經做出來了,這樣的話就當我硬廣一下我的BoomEditor)

雖然cocos下的編輯器很多,特別是在ccc出來後,基本上能轉ccc的都轉ccc了(另外,這個ccc的前身就是一樓 @王楠 的fireball),但在我看來很多開發者可能並不需要這麼集成的一個開發環境,只需要一個UI編輯器+完善的腳本解析方案,這種觀點是我在嘗試將cocosbuilder的項目用腳本關聯後得出的(cocosbuider和cocostudio都沒有完善的腳本解析方案,cocosbuider有完善的c++解析方案,並且cocosbuider和cocostudio在引用ccb文件和csd文件的時候,都只能修改引用文件的根節點屬性,這點也是非常不爽),然後我就想找一個開源的UI編輯器改成我想要的那種--

常規的UI編輯器功能+屬性可修改的布局文件引用機制+腳本(lua,js)解析方案。

UI編輯器核心功能無非是布局文件的解析,節點屬性的修改,以及渲染,解決這三個問題,基本就沒什麼技術問題了,我找了把cocos嵌入winform的資料,還發現了CefSharp--把瀏覽器嵌入winform的控制項,渲染部分用cocos本身,布局文件用xml序列化,節點屬性映射修改用CefSharp+vuejs。

然後就開搞了,大概7月份開搞,完工在8月底,工作時間的2/3來搞這個編輯器,業餘時間就是晚上大概1,2個小時,周末兩天有一天在搞

如果按照我這個思路,你的引擎最好支持腳本綁定,這樣winform向渲染模塊傳遞數據的時候,可能需要經常添加解析命令,可能是選擇某個節點的命令,可能是節點屬性改動的命令,用腳本來做的話就容易添加,改了重啟就能看到效果,用c++的話你添加了對應命令還需要編譯一次

這個編輯器還有個好處,理論上,如果把cocos的渲染模塊替換成unity3d的渲染模塊,那麼這個編輯器就可以是一個unity3d的UI編輯器(我知道我想多了,unity3d不需要額外的UI編輯器)

當然還有對於的腳本解析方案,解析代碼基本上和渲染窗口用的代碼一樣的,所以,基本上是無差別預覽

最後,歡迎各位cocos開發者去項目地址下載使用,watch和star!


參考Second Life和Minocraft,遊戲即編輯器。


先體驗市面上已有的引擎,比如 unity 和 unreal,集各家所長改進設計。

有一點非常重要,就是是否允許自定義編輯器。unity 在這方面公開了很多編輯器 api,並推出了 asset store。


什麼叫主流?

Unity?Unreal?Cocos2d?還是Frostbite?

功能模塊劃分都是一樣的,你沒有必要發明一個能同時編輯動畫和場景的麻煩。

具體實現都是不同的,根據每個引擎的特長有一些特別的關注點。

「不求有實際價值」,就想怎麼寫都可以隨意,試錯和別人告訴你錯,完全是兩個層次的理解。


推薦閱讀:

為什麼都用direct x開發pc遊戲而不是open gl?
寫小型遊戲的GUI用什麼比較好?
Unreal Engine 4 免費開放意味著什麼?
Flash小遊戲製作需要哪些準備?
cocos2dx中可以用 stl么?

TAG:遊戲開發 | 遊戲編程 | UI開發 |