有沒有人用Unity3D不是做遊戲而是做App的？

01-13

俄國有interactive lab

丹麥有 yoke

國內是說我么。。。

Home

上海杉蔓數字科技

各種奇怪東西都做了，遊戲反而沒做幾款

我做過，正在做。

和 @我也是Ted 一樣，滿滿的辛酸淚。這個app馬上就要做滿一年了，不知道會不會也掛了。

做的是個跑步app。最終為的是嵌到跑步機里用。目前只是個半獨立的app啦。

可以選人物，換服裝，選跑道。然後就開始變速跑啦~~~跑著跑著還可以看到附近的人排序。

跑道是高清視頻可以調速的播放。人物是3d模型帶動畫。

第一個大坑就是變速的視頻播放。

在我把unity原生視頻播放技巧與所有視頻播放相關插件都試了一遍之後（包括把視頻作為材質貼圖貼到3dmax里的面片上，再把這個面片導成fbx丟回unity），變速播放視頻宣告失敗。

3dmax行不通我就換pr上。直接把原視頻拆成序列圖，全部導入Unity，然後輪播圖片，靠調Time.timeScale來實現變速。這時候做的都還是PC版的，而天真的我還以為第一個坑已經過去了(～￣▽￣)～

第二個大坑就是視頻里的每一幀中，unity中人物實際移動的路線要和視頻里的路線一致。至少在相機里渲染出來人得在路上跑，不能飛到天上或者跑到樹里去了。再者也不能視頻拍到前方有人騎著摩托車，結果unity中的人物在同樣的位置看起來特別小或者特別大。

人物是3D的。所以要確定人物路線我能想到好幾種辦法。但是背景里用的是視頻啊！不是場景模型啊！！這視頻牌的還不是直線啊！！！左轉轉又轉轉~~~這讓我去哪找人物路線啊o(︶︿︶)o相機還用了兩個呢，一個固定渲染背景，一個跟著人物移動(；′⌒`)就算我找到了路線，怎麼讓這兩個相機渲染出來的場景，看起來人物在跑道上也是大難題。還要考慮背景和模型的比例。。。

涉及商業機密，詳細就不說了，反正歷經了千辛萬苦(＞﹏＜)作為一隻程序猿我都跑去畫地圖了。最後這東西功能實現了。這坑填上了。

第三個大坑就是前面做好的工程塞不進安卓測試。

第一個變速視頻的解決方案直接導致工程大小是以G來計算的，然後pc版導android測試就呵呵了。考慮到後期這跑道路線是要可以通過網路更新的，我就用了assetbundle來裝圖片資源。升級了N次視頻播放的腳本之後，看著變小的工程還分離的資源(＾－＾)V信心滿滿的塞安卓里測試。這次工程塞進去了。然後一運行內存溢出(╥╯^╰╥)於是初始化全部載入資源這條道就走不通了。年輕的我選了實時載入。以後的事實會證明這依然是個大坑。但是我不不能預知未來，於是很開心又解決了一大問題了&<(*￣▽￣*)/

第四個大坑就是聯網同步不同玩家的位置與個人信息。剛入門Unity網路這塊，所以用的是Unity自帶的networkview。然後就發現每幀同步數據的話丟包率太高，延遲太明顯。每秒同步的話直接就殭屍跳了。不要想著寫個兩點之間直線最短的勻速移動，我那是固定路徑的，路徑還可能是彎的。如果真用了這招，那可能這一秒人家明明在轉彎的，他後面的客戶端就能看到他跑步的時候抄小道了。。。最後機智如我使用了InvokeRepeating來填上了坑。。。

一些小坑就略過不說了。然後又見了客戶。確定了兩件事：1.要播放高清視頻。2.到時候很多人用，所以服務端這邊要換成能支持很多人同時使用的方式。

第五個大坑就出現了，更換聯網方式。於是每秒同步數據就沒有了，變成有變化的時候才通知更新。不僅原來的聯網介面全部重寫。同步過來的人物，移動方式也全部重寫/(ㄒoㄒ)/~~

第六個大坑就是換了聯網方式以後，原本的實時載入圖片來不及了。

迫不得已又升級了N次視頻播放的腳本，總算能流暢變速的播放視頻。終於感覺項目快要成了，於是拿出了高清的圖片資源包測試了一下∑(っ °Д °;)っ卡住了。。。以一秒25幀的速度播放視頻還有明顯的卡頓。。。而且，安卓里又塞不下資源包了o(︶︿︶)o這個問題我還在努力解決中。。。

話說，我這麼多話，難為你們看這麼久了~~~來抱抱(づ??????)づ給我點安慰。。。

unity做app，我只能說你的想法很時尚，app的渲染方式與遊戲完全不一樣

unity 按幀固定時間繪製的

app 都是按需繪製的，只繪製臟區（更新過的區域clip）就OK了

如果unity做出app，那也會非常耗電池的。

有啊，可以做虛擬現實，可以做3d應用。做這些東西的時候，需要的只是unity3d的渲染模塊，物理模塊，其他xx模塊都不大需要而已。

Unity3D官方從來沒說過自己是遊戲引擎，一直說是創建互動內容的綜合型創作工具

關注這個問題好久了，本想看下大家的經驗。不過沒有看到誰親身做了，那我來說說吧。

我做過，做死了。

導航系統頁面的前進後退要自己做，

圖片的內存管理要自己做，

安卓上成熟的布局系統的要自己做，

輸入框要自己做，

拍照要自己做，

頁面滑動的加速度要自己做。

我們都做了，還是卡的一逼，於是學習了一波渲染原理，做了各種對象池，dc合併。

一年已經過去了，競品已經死了我們才做出來。

不說都是淚。

有，我做過(以及正在做)。具體說來，相比傳統的app開發方式，用unity開發的優劣勢如下：

PROS

- 易於產生強大的表現力

- 與圖形內容親和度高，易於開發相關應用(我現在在開發的app很大程度上就是因為需要顯示3D內容而使用的unity)

- 便於跨平台

- 綜合學習成本低

CONS

- 對於重UI的app(也就是絕大多數app)開發效率低下，並很依賴於你選擇的UI框架。如果要實現符合相應平台規範的UI，比起使用相應的原生UI框架，其開發效率的差距可以達到數十倍

- app容易導致設備發熱，增加耗電量

- 發布包較大

- 較難調用各平台的原生功能

- AOT依然是iOS的噩夢之一

- 授權成本

做過3個月多android開發的unity客戶端。zhutaorun (zhutao) · GitHub有android和unity項目

是可以的，我遇到幾個多平台視頻直播活動使用unity做的，其中可以內部嵌入遊戲的部分，加上虛擬互動部分。

其實已經離職的公司想做App，一開始知道unity可以做多平台發布就讓我來的，後來接觸了外包團隊，我轉去android幾個月。

具體點上

1.從包大小上，同樣的功能，比如攝像頭拍照工作，unity的包有10M，android只要4M就行了。在實際應用中，除非用戶粘度很高用戶手機性能很高。大多數在卸載APP就是把單一功能用的少而且安裝包大的應用優先刪除。

2.在APP中大部分都會有個地理位置收集，別說你沒注意，只是大部分人不關心而已。unity要做這個是難的，我在短時間裡是沒解決的。android本身容易實現多了。

3.對於android源生的支持這塊，unity完敗，在網路通信這塊，unity是要自己去搭建，我是沒看到開源可以直接拿來用的框架，android這塊很多，也很成熟。

4.在開源這塊，unity有assetstore,國內蠻牛，android的開源我見到更多，github,Git@OSC代碼託管。

5.從實際需求出發，脫離應用場景考慮是耍流氓。你想要遊戲在手機那種操作方式，抱歉這需求太天馬行空。像APP下拉載入這個功能在開源等地方容易找到，unity做類似的效果，抱歉愚鈍，沒研究到那步就改做android.

6.從研發時間上考慮。unity的一款應用研發周期，一款簡單的小遊戲合集（益智百寶箱）應用詳情 - 應用寶官網（策劃2人，美術3人，程序3人），基於已有框架，從前期策划到美術一版二版三版到研發到上線，歷時近4個月。而APP開發一個成熟的外包團隊（6人，項目經理，美術，android,ios,後台，測試各1）是要6個周到2個月。這是在需求不做大的變動情況下。看起來android研發時間短，實際想清楚產品的需求是要更久，想了一個多月，產品方向完全變掉了，在一個多月方向又改了。只能說想多太多的CEO和沒啥主見的產品對於開發人員是噩夢

7.考核標準不同。遊戲可能更純粹點，為了賺錢或者為了好玩。看到宣傳是流水多少。多少玩家，付費多少。盈利是和其他發行商分成的。APP目前很多是平台類，或者單一功能大家用的比較多。註冊用戶多少，活躍用戶是比較看中的。APP本身產生盈收的少，是在用戶量大了後，佔據市場份額上有說話勸，或融資或插廣告或買用戶信息或者個性化引導消費

8.環境，一個產品計劃書或者遊戲Demo拿天使目前不容易。拿錢是要儘快出產品的，所以哪個更容易實現選擇那個，更現實點。

9.關於這個問題本身，我想說，當你問這個問題，也面臨一個選擇的話，我問過類似的問題，我想說。堅持自己的的方向，不要放棄。

10.Unity多平台分布是優勢，但後期維護上，APP源生更好點。

總結

工具選擇是需求的，2D和3D就可以理清。APP是更關注文字和圖片內容，偏信息展示；unity更關注手和手機的交互，更關注操作的樂趣。

目前的web單頁面應用，用css做一個水杯、或者一朵花，一點簡單的動畫，都算是『高端』『牛b』的了，但是我本能實在不覺得一個水杯有什麼牛逼的。用成熟的3d遊戲技術來實現哪怕普通的todoList任務版，牛刀殺雞會不會更遊刃有餘呢？

方法可行，不過也要了解原生系統的一些API

封裝太多，發布之後占存太大。感覺開發App還是交給其他工具吧。比如一個人想下載一個單純的日曆工具，他會選擇1M大小還是10M大小的應用？

Game is part of App

以前公司做的一套3d監獄管理系統就是u3d做的

費了很大的勁、要和設備聯動、要嵌入網頁

非常麻煩

這是我們公司剛用Unity做的蘋果應用

可以做一個煎雞蛋的APP，我說真的煎雞蛋

人體解剖學圖集就是unity做的，超好用

之前曾經實習過的一家公司做的一款教育類app（榫卯）tag Design | 榫卯，我也參與過最新版的改版，app裡面主界面的27個可交互拆卸的3d榫卯結構都是三維建模師製作，unity工程師實現的，榫卯曾經入選過2014App Store年度精選，也算是個老的案例了吧。

有

有大學室友之前的同事，現在在做U3D，不過是做一個機房管理系統，用U3D做模擬

感覺這個會是未來大方向

一直在用UNITY做APP，主業是webplayer，當然，那是5.4以前了，現在unity也拋棄了webplayer，只是現在HTML5在運行大數理量3D場景的優勢還是不如webplayer。。。。。。。。

說說unity做APP吧

重要的事說三遍！優化！優化！優化！unity因為是開發遊戲的，所以天然就有APP開發功能，只是大多數使用APP的用戶硬體平台都相對弱一些，尤其是手機端上，所以優化是第一需要注意的問題。

第二就是模型，我的意見就是如果你要用到3D模型，請一定要找遊戲製作行業里的美工給你們做，因為他們知道如何做出合格的簡模（事實上簡模水平是優化效果的重要因素），千萬別找那些上了個學習班或自學了幾本建築效果圖的書就出來的建模人員，不然你還需要額外付出他們的學習成本---學習如何做出品質過關並且數據量最少的簡模。

PS：簡模的價值在於，只用最多幾千三角面甚至不超過一千三角面，加上合理使用紋理做出來的模型，在外表的表現上不會比效果圖和動畫里幾十萬甚至上百萬三角面的建模物模型差多少。想想看，你達到了完美效果80%甚至85%的水平，卻只使用了100%水平需要數據量的1%甚至更少！尤其是在使用到了物理碰撞計算的場景中，這種數據量上的差距，可以極大的節省CPU的計算量！

第三就是程序了，建議使用C#作為開發語言，還有，最好腦子活一些，手勤一些，UNITY雖然功能已經很強大很全面了，但很多時候，你依然需要自己寫一些小工具來提高你在UNITY當中數據和模型處理效率。

第四個，說說基本開發流程吧，先別想要太多功能和效果，先做出一個最簡單的，可以確定執行和使用的場景（最好是在目標端上使用驗證過），解決了這個以後，再往裡面加功能，加效果。如果你一開始就寫了一大堆功能和效果，不好意思，當你程序出錯時，你會被淹死在這一堆的功能和效果的細節當中。。。