1樓：猴與花果山
各自的好處和毛病：
1，用單個Scene你會發現Unity的最大優點——「乙個優秀的編輯器」這條性質就不存在了，因為到最後你是看不清楚自己在場景和Canvas裡究竟放了什麼了。但是單個Scene不會遇到資料傳遞問題，Scene之間的資料傳遞始終是Unity忽略的玩意，弄了個DontDestroyOnLoad補丁，但是這個補丁隨著Scene變多也會出現各種不可思議的問題，當然大多是因為我們開發者是地球人導致的，比如多個場景對同乙個東西（作用一樣）做了不同的DontDestroyOnLoad的GameObject導致邏輯混亂等，當然Unity作為乙個只能做做Demo的工具，從來就沒想過做個demo還要把工程弄這麼大，甚至還要維護，所以這塊從來也就沒重視過。
2，多個Scene是相對接近傳統遊戲開發的概念，但是Unity提倡的是不到萬不得已別開新Scene，比如：標準JRPG，大地圖移動到戰鬥之間才做不同的Scene，而不是按下三角出現選單就是乙個新的Scene，這是和傳統開發思維不一樣的地方（傳統遊戲開發也沒有Scene這種概念，不知道被誰先帶了個頭，Scene這個詞來描述這玩意也算合理），大地圖移動場景到戰鬥場景是標準的JRPG了，也正因此，才會有上面說的資料傳遞資料儲存的問題，比如戰鬥開始前角色在哪兒，戰鬥完回來以後角色還得在哪兒，且角色之間的資料是要同步的，比如排在第乙個的人戰鬥中掛了，大地圖上顯示的就應該是排在第二個的人之類的——這個工作，用「湊效果」的方式還算勉強能實現，所以就再也沒人重視這麼做對不對了，it just works（這根本不是程式設計師應該有的態度）。
你說我一句好處沒提？不是的，只要沒有壞處，在unity就是好處了。所以該咋分，還是看你自己做的時候的取捨了——如果你記憶力好，對於混亂的東西管理能力夠強，建議不要沒事就來個Scene；而如果你覺得靜態類傳遞資料、DontDestroyOnLoad反正都能工作，不管方法好不好，能跑起來就萬歲，那多開點Scene便於維護也沒啥毛病。
2樓：皮皮關
直接說結論。沒有優劣之分，也跟Unity引擎沒啥關係，這個只跟開發團隊有關。
如果只是乙個非常簡單的遊戲，那麼多個場景都沒必要。但是遊戲畢竟是乙個多人合作開發的東西，牽扯到美術資源、關卡搭建等等，所以一般都會做成多場景同步進行開發，就算是做成單場景也會進行層次切分。
還有一種情況，類似於MMO的專案，如果有多個副本，而且副本的功能很單一，與大地圖的內容聯絡很弱，這種情況之下也會做成乙個副本乙個場景。
一言蔽之，就是多場景很多時候是為了讓團隊分工更加清晰，專案更好管理。
3樓：枯藤昏鴉
看遊戲內容，和團隊合作方式。
多scene有易管理的優點，但也有場景間切換邏輯複雜的缺點。
單場景一切資源都在自己的掌控之中，但是無法視覺化管理很麻煩。
4樓：有木桑
乙個還是多個scene，與unity無關，與遊戲內容、團隊分工方式有關。
我個人習慣是在乙個場景啟動遊戲之後，切進主場景，之後遊戲內容的載入和解除安裝全自己控制。除此之外會保留乙個空場景用於熱更新。
也就是一共需要三個場景。
學建模是場景好還是角色好
ThingJS 建模固然區分場景 角色，但是也不能非黑即白，還是看不同的行業需求。如果你選擇的是我所在的物聯網3D視覺化行業，學習環境 場景 建模就夠了，需要建立大型場景開發思維，比如 上帝視角 平面視角 室內巡航 做建模這一行，理解什麼是3D開發，會對你做專案更有幫助。其實行業內的技術美術特別少，...
你想要乙個孩子還是多個孩子？
多個，因為，我會很喜歡我和我喜歡的人的小孩，而且陪伴孩子們成長長大的過程，又美好。我的生命和心愛的人結合，是多麼神聖的一件事啊。 何娘娘的倆崽兒 他倆摟一起的時候我想 媽耶，太可愛了吧，好有愛，生生生，我還能再生乙個，都是我的小心肝小寶貝。等一會他倆打起來了，我只想都扔出去乙個也不要，生什麼孩子，是...
乙個docker容器中執行多個服務還是弄一堆docker容器執行？
Hat Joker 通常是一台虛擬機器安裝乙個Docker，也可以多台機器安裝多個Docker，組成Docker集群。每個Docker裡面包含了諸多映象，執行映象產生容器，乙個映象可以執行多個容器，每個容器運營乙個微服務。 創帆雲 每個docker建議是單獨的資源和服務 當你docker玩得久之後，...