為什麼unity願意用c#作為代碼語言,而虛幻卻使用c++？
之前問題提的有毛病，重新提一下，主要思想是這個
瀉藥，作為一個很喜歡這個引擎的UE黑頭子，退乎前來理性分析一下，希望社區的哥們們輕點錘。同時我發現很多社區的朋友因為用多了U++，變得無法分辨引擎特性和語言特性了，這裡權做一些指正。
從結論來說，UE的這套東西成型非常早（C++04年代），並且經過了非常非常長期的迭代，所以從設計角度看現在處於一個尷尬的境地。比起隔壁聯合的C#套裝，比較落後。在現在的機器上，比起一些用lua的inhouse，性能優勢也好不到哪裡去。當然這裡只是闡述當下的客觀事實，並不是我對Unreal有什麼輕視鄙視的想法。軟體工程本就沒有銀彈，Unreal現在的體系，只能說是Epic在多年遊戲製作中面向實際需求，完善內部工作流進行迭代的直接結果。
比起Unity這樣的輪子專業戶，Unreal面向需求（特別是內部需求）的味道非常強烈。那麼對立地，設計層面上就必然顯得不是那麼優雅。
U++ UnrealScript
虛幻只提供C++作為文本代碼語言，只能說有歷史遺留原因，也存在它自己的一些考量。
首先Unreal不用C#，並不是說它就不要腳本了。只不過比起使用現成的C#，lua等腳本，Unreal選擇基於C++，造一套虛擬機，實現一套自己的腳本。這套東西，當年叫做UnrealScript，如今叫做BP，打底的就是大家所說的U++。至於為啥，首當其衝的自然是性能。UE的GC就是經典例子，C++實現的非通用GC，可以滲透到每個細小的角落進行優化（活用幀概念、考慮Streaming等），性能上基本算是無痛。
UE3的年代是Kismet和UScript並存的，並且有大量的代碼遺留下來了。反射系統裡面你可以看到UScript的各種痕跡，BP裡面你也能看到各種Kismet的遺產。通用BP節點本身，基類也是以K2為代號的，取意自Kismet2。
那麼這裡就可以談下我題首引出的那個問題了。作為腳本的底層，U++中的反射序列化網路GC等等一大堆特性到底屬於語言特性還是引擎功能呢？結論是很顯然的，它們是Unreal的引擎功能，同時是UnrealScript的語言特性。所以U++的各種東西都圍繞著基類UObject來進行，而不是直接對C++進行語言機制補全。當UnrealScript被腰斬，這個RuntimeSystem透過C++直接暴露出來的時候，各種違和感就突顯出來了。
用人話來說，C++拖著一個龐大的運行時系統，就是呈現在你面前的U++了。
被幹掉的文本腳本
那為啥Unreal扔掉了UnrealScript呢？這可以算作Unreal面向內部需求採取的一種折中了。維護一套文本腳本比較費神是一點，但最大的原因在於Epic可能真的用不上這套東西。
作為主機平臺的FPS專業戶，Epic對文本腳本的需求可以說不是那麼重。不像MMORPG，FPS遊戲的大部分邏輯，都在場景裏跑著的一個個Actor上。不像ARPG，有那麼多複雜的技能。在實踐中，策劃甚至程序直接拉拉連連看，向場景裡面一丟，就能實現大部分的功能。影響性能的，直接重構到C++。所以Epic發現自己真的用不了太多UnrealScript這團雞肋了。
於是壯士斷腕，奧利給幹了，一刀下去UnrealScript就人間蒸發掉了。美國楊過，就這麼橫空出世了。
但是這刀下去，帶來了一些災難性的後果。爽了一時，爽不過一世。隨著Unity步步緊逼，Unreal開源，Epic開始硬著頭皮推進商業化社區化的大潮。各種各樣的團隊，多元化的需求，這時候開始湧現出來，獨臂俠楊過這時終於發現耍不了雙刀了。尤其是到了我們天朝更是水土不服，沒了文本腳本，多人協作簡直要了老命了。版本管理直接暴斃，複雜邏輯一直編譯，種種蛋疼之處層出不窮。
BP好用嗎？對我個人來說當然是好用的，對於做FPS的關卡設計來說那肯定是香的。但是痛就痛在為什麼沒有文本腳本呢？對於一些類型的遊戲（MMO等）和超大型項目來說，這痛簡直是痛到老二上了。
新時代的舊遺產
時光荏苒，在遊戲之外，Unreal在視覺領域也披荊斬棘，打出了一片自己的天下。Unreal本身的功能已經強大到無與倫比，引擎的體量也膨脹到恐怖如斯的程度。
這時的Unreal想進行重構，已然是一件艱巨無比的任務了。迪拜塔都衝天上了，想動動地基何其容易啊。再說用戶這麼多，並且藝術領域的用戶羣體也大，完全重構的大版本換代，對用戶和Epic自身而言都是很難接受的。Epic自然又選擇了類似Win10的長期支持，滾動更新策略。
自此，格局就這麼定下來了。作為吠舍羣體，勞苦功高的程序員羣體只能看著婆羅門美術們在Editor裡面喫香的喝辣的，同時自己在VisualStudio裡面喫翔的喝拉的。
讓人不那麼絕望的是，這個引擎還是在逐步變好的。很大一部分貢獻來自社區支持，如果你想換掉蹩腳的UMG，有Noesis這樣的GUI框架支持。如果你迫切的需要一套文本腳本，自有unlua等任君選擇。
但有那麼點不舒服的是，Unreal社區現在有股盲信盲從，滿口官方工程師全能神，強無敵秒超平的不良風氣，甚至很多人覺得官方就是最好的，從不關注甚至鄙視第三方組織的貢獻。這與官方構建開源社區的理念也是背道而馳的，完全不利於社區的長期發展。
每個寫過點編輯器和BP前端的少年們，都會懷想起當年自己在BP Graph裏揮線如劍，縱橫馳騁的英姿颯爽。每個奮戰在RHI前線，徹夜擼管（線）的哥們們，又何嘗不會於深夜憶起往昔，追念那Material Graph中的種種快意恩仇呢。
這個估計只能問當初開發unity那幫人了。
unity當初引入mono 和c#估計只是當成個腳本語言在用。 實際上最早的時候你是可以在運行的時候直接修改邏輯代碼而不需要關掉運行模式的， 只要你按照特定的規則寫。現在想這麼幹已經有點難了。雖然你依然可以在運行時修改代碼和編譯， 但難度增加很多，經常會丟引用什麼的。實際上最早unity推薦的編程語言是javascript 或者現在大家都叫他unityscript… 後來才換成推薦語法比較嚴謹的c#。
mono虛擬機當初最大的好處就是跨平臺， 2.x時代unity就經常被用來做3D 瀏覽器應用和3D頁遊。 3.x後可以幾乎不用修改的部署到ios android 等各種平臺。而其當時的遊戲開發幾乎都要單獨為每個平臺特製。
不過後來貌似unity打算拋棄mono ，畢竟運行效率還是有點低的。
UE 這邊選擇c++ 必然因為UE是一個很重型的引擎， 需要比較高的效率。 而靈活一方面是通過Blueprint 藍圖來提供的。 另外現在UE也可以通過插件來支持 C# 和 Lua 之類的。
誰跟你講 C# 沒有指針的……
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/unsafe-code-pointers/?docs.microsoft.com題主更新了問題，在此回答為何虛幻使用 C++。
其實可以反過來想，想用 C# 也好 C++ 也罷，市面上都有選擇。
C# 和 C++ 用作遊戲引擎還是各有取捨的。我並不在遊戲業界，只能說一點淺薄的看法：
C# 的主要好處來自於內存安全，主要風險來自於 GC pause。而 C++ 的主要好處來自於極限執行效率，主要風險則來自於內存安全。所以其實問題的核心在內存安全上。不要小看內存安全的威脅，稍微搞不好可能就會導致項目難產的，很多項目組是承受不了這個風險的。
- Unity本身引擎是用c++代碼開發的，早期官方包裝了三種腳本語言JavaScript、C#、Boo供開發者使用，降低使用者開發難度。其中c#使用開源mono，使用最廣泛也最流行，也是Unity唯一倖存的腳本語言。又因c#的效率等諸多問題，再後來Unity推薦使用IL2CPP，轉c#為c++提升效率。目前又推出Brust編譯器（使用LLVM將.Net轉化為機器碼），使用Dots開發模式更進一步提升效率。
- Unity引擎c++層是黑盒模式，開發者是接觸不到的，當然也可以花錢購買源碼。黑盒也許保證開發更可控，避免濫用吧。
- Unity國內為了熱更新方便，第三方開發者引入Xlua，Slua，toLua，ILRutime等框架，基本核心效率邏輯可以採用c++或c#寫，lua腳本作為非效率業務邏輯開發。
- Unreal 核心引擎邏輯也是c++，早期官方也包裝了UnrealScript供開發使用，來降低使用者開發難度。後來可能大量開發者覺得腳本層與引擎c++層面交互不夠效率，腳本語言特性不夠豐富等諸多原因，改為c++模式開發了，但c++開發門檻還是較高的，這可能是它得不到很好推廣的一個原因吧，當然Unreal也自己可引入其他更好的腳本語言來做一部分業務邏輯開發。
- Unreal是開放了源代碼，可以更自由的使用引擎層，但讀懂也非常的難~~~~~
總結：Unity C#易用順手，對初學者友好。Unreal c++上手難度大，需要很強的駕馭能力，沒有中間層追求效果效率。
Unity早期支持很多種腳本語言，比如BOO、Unity Script（JavaScript for Unity）等等。但是新版本中不再推薦使用了，現在Unity的推薦開發語言為C#。
那麼，為什麼Unity選C#，而UE4不選C#？
1、Unreal Engine成熟的時間比C#還早
UE4是從UE3、UDK慢慢發展過來的，而UE3發佈於2005年前後，發布時已經伴隨成熟的遊戲產品了。
算是成熟版本的C# 2.0發佈於2005年11月，而C# 3.0直到2007年才正式發布。
客觀上UE3、UE4不可能採用C#作為腳本語言。
2、Unity支持C#是多方面考慮的結果
Unity 3.0的發布時間大約在2010年前後，在Unity早期立項時，選擇C#的客觀條件已經成熟。
可喜的是Unity沒有選錯語言，而且抱著微軟大腿少走了很多彎路。開發者們也非常喜歡C#語言，用過的都說真香 ：）。
Unity早期打算支持多種編程語言，包括不限於C#、Boo、UnityScript等等。這說明一件事——Unity當時打算通過降低編程門檻的方式吸引大量遊戲愛好者和初級開發者。用現在流行的話來說就是戰未來。
事實證明，Unity的一系列商業策略確實成功了，常聽到的說法是Unity對UE在商業和技術上實現了彎道超車。
3、大幅度改變腳本架構成本很高
像UE、Unity這種體量的成熟引擎，它們的編程體系已經經過了無數次優化和測試，達到了比較好的水平。強行在現有情況下加入對新腳本語言的支持其實是非常困難的。
為什麼這麼說呢？因為：如果新加入的語言不成熟，就不會有人去用；而如果沒有人用，新系統就不會成熟。這是個負反饋疊加的狀態。
除非市場環境有巨大變化，Unity和UE都不會大幅度改變現有的編程方式。
從2020年的時間點看，由於現在正處於一個「遊戲多元化」的歷史階段。手機遊戲、PC遊戲、家用機遊戲、HTML5遊戲等等，都有各自的市場。每個市場特性不同，從而每個市場都有更青睞的引擎。
綜合來看，不同的引擎有它最適合的語言。目前UE4採用藍圖和C++，Unity採用C#（某些項目會加上一點Lua），算是達到了一個均衡的狀態。
推薦閱讀：
