可以的。
1.遊戲碎片化。U3D 引擎有個很有力的特色，就是實時編譯執行。這意味著無論在任何時候，只要按下執行圖示，當前的場景就會進入可執行狀態。這導致了遊戲在開發的過程中經常陷 入一種不應當的自信狀態。同時也導致了遊戲內容長期處在碎片狀態下，並低估遊戲功能整合時可能遇到的困難。
2.資源管理是 U3D 引擎的一個難點。U3D 的資源管理系統因為跨平臺的緣故和作業系統的檔案系統是脫鉤的，需要熟練的掌握 Resources 目錄和 Assetbundle 的技術才能靈活的控制遊戲中的資源使用情況。但這一工作時常會被簡單的理解為將資源放置在遊戲工程目錄下，剩下的交給引擎自己搞定 ……
3.需要自己做資料系統。我們如今國內研發的作品，絕大多數是資料密集型（策略、經營、卡牌、KRPG），這和 Temple Run 這樣的遊戲型別有些不同。資料密集型的遊戲需要採用資料驅動的形式來進行遊戲的設計和開發，但是U3D 提供的框架是一個程式碼驅動型的結構（對於原型開發來說極為有力）很多時候會讓研發團隊陷入泥潭 —— 看起來功能開發出來了（只要在U3D的物件檢查器裡調調引數就能工作），卻遲遲無法進入大規模製作階段（策劃拿著資料表格卻無法應用到遊戲裡）。U3D 引擎本身也沒有提供任何在資料方面的支援，資料表要麼需要自行處理，要麼需要自己尋找嵌入式的資料庫解決方案。
4.網路連線部分其實也是類似。U3D 本身整合的網路模組並不是為大規模 C/S 結構的遊戲所設計，常需要自行開發一套客戶端和伺服器結構。當然也可以求助中介軟體來解決 …… 但是容易讓人迷惑的地方在於，U3D 既可以使用 .net 的網路機制像端遊一樣工作，也退一步可以用加密的 www 機制，當一個簡單的頁游來處理。如何抉擇是個難題，貿然貪多求全往往換來遙遙無期。
5.測試 U3D 開發的遊戲亦一個很麻煩的過程。原因也是那個幾乎不會崩潰，隨時可執行的場景/邏輯混成編輯器 —— 它會讓開發團隊誤算自己當前的遊戲完成度，以及需要什麼樣的測試。
可以的。
1.遊戲碎片化。U3D 引擎有個很有力的特色，就是實時編譯執行。這意味著無論在任何時候，只要按下執行圖示，當前的場景就會進入可執行狀態。這導致了遊戲在開發的過程中經常陷 入一種不應當的自信狀態。同時也導致了遊戲內容長期處在碎片狀態下，並低估遊戲功能整合時可能遇到的困難。
2.資源管理是 U3D 引擎的一個難點。U3D 的資源管理系統因為跨平臺的緣故和作業系統的檔案系統是脫鉤的，需要熟練的掌握 Resources 目錄和 Assetbundle 的技術才能靈活的控制遊戲中的資源使用情況。但這一工作時常會被簡單的理解為將資源放置在遊戲工程目錄下，剩下的交給引擎自己搞定 ……
3.需要自己做資料系統。我們如今國內研發的作品，絕大多數是資料密集型（策略、經營、卡牌、KRPG），這和 Temple Run 這樣的遊戲型別有些不同。資料密集型的遊戲需要採用資料驅動的形式來進行遊戲的設計和開發，但是U3D 提供的框架是一個程式碼驅動型的結構（對於原型開發來說極為有力）很多時候會讓研發團隊陷入泥潭 —— 看起來功能開發出來了（只要在U3D的物件檢查器裡調調引數就能工作），卻遲遲無法進入大規模製作階段（策劃拿著資料表格卻無法應用到遊戲裡）。U3D 引擎本身也沒有提供任何在資料方面的支援，資料表要麼需要自行處理，要麼需要自己尋找嵌入式的資料庫解決方案。
4.網路連線部分其實也是類似。U3D 本身整合的網路模組並不是為大規模 C/S 結構的遊戲所設計，常需要自行開發一套客戶端和伺服器結構。當然也可以求助中介軟體來解決 …… 但是容易讓人迷惑的地方在於，U3D 既可以使用 .net 的網路機制像端遊一樣工作，也退一步可以用加密的 www 機制，當一個簡單的頁游來處理。如何抉擇是個難題，貿然貪多求全往往換來遙遙無期。
5.測試 U3D 開發的遊戲亦一個很麻煩的過程。原因也是那個幾乎不會崩潰，隨時可執行的場景/邏輯混成編輯器 —— 它會讓開發團隊誤算自己當前的遊戲完成度，以及需要什麼樣的測試。