Re: [問題] 目前玩遊戲最強的是哪隻手機呢？

看板MobileComm作者 (小鳥)時間8年前 (2015/10/18 11:31), 8年前編輯推噓35(35推 0噓 38→)
留言73則, 33人參與, 最新討論串4/4 (看更多)
原文吃光光 既然下面已經提到遊戲開發問題了 那這個有稍稍稍微涉獵的小弟就可以稍微地說幾句 以下是某音樂遊戲開發者所說的，想想他所說的，好像也很合理。 ─── 這裡是一個遊戲開發者，在做手機遊戲。 聽說iOS機種少，開發比Android易。 看似很有道理，我亦對此深信很長時間。 但實戰上，我做Mobile遇到的大問題都是來自iOS。 早前Apple禁止32bit App上架，強制所有新binary都要64bit。 32bit轉64bit，一開始有問題是一定的，引擎和很多第三方軟件都未有充分準備， 但不少bug到現在還是未解決。 嚴重到連Project都可以Build不到。 轉64bit，是很大轉變，出問題我接受。 但每次Apple推出iOS新版本升級，總是有某些機種玩遊戲出問題。 版本更新，在Android問題很少，就算有問題亦很容易更新。 Google Play上submit app要兩小時，App Store就一星期 ( 已經沒算上被Apple reject的時間 ) 就算當日已立即解決了Bug，各位用家都要硬食一星期。 最後才說回機種，iOS機種少的傳說已經不存在。 現在出到iPhone6S，現時也有不少人在用iPhone4S，4S到6S有多少台iOS機呢? 我相信各位都要數一數。 就算同一個機種也不是表現一樣，就算同一個iOS Version都會不同的。 不少時候Android更易處理 ( 山寨機+ROM就不要說了 )。 奇妙的XCode我不想說了，最後付圖。 http://i.imgur.com/hCagGqp.jpg
── 原文連結:https://www.facebook.com/878733358870051 (原文權限公開，所以應該也沒有詢問問題了) 其實從一開始，iOS裝置少，開發條件低，相對Android的多裝置，多解析度等等，相對簡單 可是當Google意識到這問題之後，開始整合所有手機的差異，讓開發變簡單 然而，現在的蘋果正卡在這裡 當iPhone越出越多，螢幕越做越大的的同時 相對改變的不只是使用者對於手機的體驗 還有開發者對於遊戲的優化考驗 尤其現在Android的開發條件更低，連我手邊測試的遊戲，第一手檔案也是apk而不是ipa 才會有在下面推文說偶像大師在Android比較順的說法 這邊給原PO一個參考 如果要玩的是2014年下半年以後的遊戲，請用Android 要玩的是2014下半年之前的遊戲，請選iOS Android的話，就M9或是S6 iOS就看你的需求了 以上。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 117.19.1.34 ※ 文章網址: https://www.ptt.cc/bbs/MobileComm/M.1445139084.A.E78.html
推
10/18 11:41, , 1F
拍照音質速度遊戲底下都狂推文哀鳳的榮景 別破壞啦
10/18 11:41, 1F
推
10/18 11:41, , 2F
感謝資訊
10/18 11:41, 2F
推
10/18 11:43, , 3F
原來現實層面是這樣的，受教了
10/18 11:43, 3F
推
10/18 11:44, , 4F
中肯推
10/18 11:44, 4F
推
10/18 11:49, , 5F
容易更新 常更新 這是一個很重要的事情
10/18 11:49, 5F
推
10/18 11:52, , 6F
推 情勢在變了
10/18 11:52, 6F
→
10/18 12:00, , 7F
漲姿勢了！
10/18 12:00, 7F
※ 編輯: Angrierb (117.19.1.34), 10/18/2015 12:04:17
推
10/18 12:04, , 8F
其實就等新遊戲都用64bit 來開發時 ，ios應該就沒這
10/18 12:04, 8F
→
10/18 12:04, , 9F
樣的問題了
10/18 12:04, 9F
→
10/18 12:05, , 10F
解析度的問題不大 ，4.7跟5.5之後就成熟了 ，會拿iP
10/18 12:05, 10F
→
10/18 12:05, , 11F
ad pro 打電動的人應該不多了
10/18 12:05, 11F
推
10/18 12:06, , 12F
有在玩遊戲的人應該會發現跨平台遊戲出問題時，率先
10/18 12:06, 12F
→
10/18 12:06, , 13F
更新的都是android，我玩的遊戲不多，但印象中神魔
10/18 12:06, 13F
→
10/18 12:06, , 14F
就是這樣。
10/18 12:06, 14F
推
10/18 12:09, , 15F
那張圖好好笑
10/18 12:09, 15F
→
10/18 12:10, , 16F
apple審核太久了,更慘的話會因為奇怪的原因退件
10/18 12:10, 16F
推
10/18 12:12, , 17F
想到之前玩神魔的時候，ios有bug常常拖到下個版本才
10/18 12:12, 17F
→
10/18 12:12, , 18F
一起修好
10/18 12:12, 18F
神魔啊…最經典的事情是木妹罷工 現在也想到一個事情 Deemo 2.1 Android已經更新了 iOS還遙遙無期… 「能夠即時更新」也是對於開發者一個重要因素 從上面我舉兩個例子就看得出來了 ※ 編輯: Angrierb (39.13.209.141), 10/18/2015 12:20:28
推
10/18 12:34, , 19F
可以問一下 GOOGLE整合手機差異的例子?
10/18 12:34, 19F
這部分我比較不會說明，所以我提供我問到的結果（就開發面） http://i.imgur.com/GGklAvN.jpg
使用者的遊玩體驗…下面那張LL名圖可以解答你
→
10/18 12:37, , 20F
安卓的碎片化惡夢正悄悄地造訪iOS
10/18 12:37, 20F
→
10/18 12:41, , 21F
嗯，審核機制至少讓app store少了些垃圾
10/18 12:41, 21F
這的確不可否認，但我記得 Google也有人工審核，而且速度更快（填分類問卷） 品質的話，那應該是各遊戲公司要把關了…
推
10/18 12:47, , 22F
推 專業
10/18 12:47, 22F
推
10/18 12:50, , 23F
10/18 12:50, 23F
→
10/18 12:50, , 24F
當初iphone 6 plus剛出的名圖XD
10/18 12:50, 24F
※ 編輯: Angrierb (117.19.1.34), 10/18/2015 12:55:56
推
10/18 12:54, , 25F
你說再多有人還是只會跳針白貓
10/18 12:54, 25F
推
10/18 13:09, , 26F
iPad 4在白貓的表現也不怎樣，閃退、lag一樣都有
10/18 13:09, 26F
推
10/18 13:15, , 27F
整合手機差異的例子我來提吧 安卓因為定位上一開始
10/18 13:15, 27F
→
10/18 13:15, , 28F
就要跨各解析各種硬體大小尺寸，所以本身就有定義好
10/18 13:15, 28F
→
10/18 13:15, , 29F
dpi分級、高階低階硬體配備判斷api等，所以寫app的
10/18 13:15, 29F
→
10/18 13:15, , 30F
人有各種預先定義好的判斷條件可以用，願意多花心思
10/18 13:15, 30F
→
10/18 13:15, , 31F
下去的話，各階層的安卓手機都能有符合配備能力的良
10/18 13:15, 31F
→
10/18 13:15, , 32F
好體驗；就算開發者懶，預設的相容方式也能保有堪用
10/18 13:15, 32F
→
10/18 13:15, , 33F
的基礎，頂多畫面糊了點。ios這部份一開始沒被列入
10/18 13:15, 33F
→
10/18 13:15, , 34F
考量，所以我知道的例子是，iphone之前要加大尺寸一
10/18 13:15, 34F
→
10/18 13:15, , 35F
直都要固守解析度的等比例，例如加長也要剛好只能多
10/18 13:15, 35F
→
10/18 13:15, , 36F
放一排桌面圖示，app沒跟上就是黑邊，這在安卓上是
10/18 13:15, 36F
→
10/18 13:15, , 37F
看不到的，而第一個破壞解析度定律的iPhone 6 plus
10/18 13:15, 37F
→
10/18 13:15, , 38F
也才會有如上圖的畫面惡夢
10/18 13:15, 38F
→
10/18 13:48, , 39F
s810的無誤 只是燙了點XD
10/18 13:48, 39F
推
10/18 13:57, , 40F
那可以請問一下為什麼卓機跑白貓這麼頓嗎 我試過M9
10/18 13:57, 40F
→
10/18 13:57, , 41F
和SHIELD跑白貓真的沒有5S順
10/18 13:57, 41F
→
10/18 13:58, , 42F
可能白貓的工程師裡面缺乏安卓專業人才吧
10/18 13:58, 42F
→
10/18 13:58, , 43F
也不是說頓 流暢度是OK的 但沒有5S絲滑的感覺
10/18 13:58, 43F
推
10/18 14:03, , 44F
有可能本身就配備cover不了啊。安卓在系統架構上是
10/18 14:03, 44F
→
10/18 14:03, , 45F
有劣勢的(為了跨設備所以用虛擬機器)，所以現在堪用
10/18 14:03, 45F
→
10/18 14:03, , 46F
都是歸功於硬體的進步，如果本身白貓的運算要求就真
10/18 14:03, 46F
→
10/18 14:03, , 47F
的很高的話，反應速度上安卓劣勢就會變明顯
10/18 14:03, 47F
推
10/18 14:26, , 48F
我用ipad2跑白貓也不太順啊 反而z3好多了
10/18 14:26, 48F
推
10/18 14:28, , 49F
推推專業文
10/18 14:28, 49F
推
10/18 14:46, , 50F
這不就之前我提的 apple 裝置越來越多會接觸到 andr
10/18 14:46, 50F
→
10/18 14:46, , 51F
oid 的痛 像尺寸問題就推 fargment 處理
10/18 14:46, 51F
推
10/18 14:51, , 52F
至於通知問題 目前 ios 比較麻煩 等 google 新 gcm
10/18 14:51, 52F
→
10/18 14:51, , 53F
出來 ios 可以使用
10/18 14:51, 53F
推
10/18 15:09, , 54F
這篇太專業 戰不起來
10/18 15:09, 54F
推
10/18 15:21, , 55F
平常在戰的來酸會褲子瞬間炸裂
10/18 15:21, 55F
推
10/18 15:28, , 56F
LLSIF在安卓上也有黑邊啊
10/18 15:28, 56F
先謝謝sokayha大替我說明那麼多OTZ 我想樓上提的黑邊應該不是跟上面那圖一樣吧 如同Dynamix在iPad上面玩有上下兩條黑邊是遊玩體驗問題 玩著三邊都要控制的音樂遊戲，當然是16：9比較方便 我想LL原因應該也是一樣 不然不妨拍個照或是截圖，來看看到底是Bug還是遊玩體驗問題 ※ 編輯: Angrierb (117.19.1.34), 10/18/2015 15:40:32
推
10/18 15:56, , 57F
10/18 15:56, 57F
推
10/18 15:57, , 58F
我指的是這個啦，當年iphone5拉長，一般app沒跟上就
10/18 15:57, 58F
→
10/18 15:57, , 59F
會有黑邊 不是那種遊戲、影片故意維持16:9的case
10/18 15:57, 59F
推
10/18 16:16, , 60F
做遊戲做到要常常更新根本是你自己廢
10/18 16:16, 60F
→
10/18 17:01, , 61F
那很多不斷追加新內容的遊戲可能都很廢(?
10/18 17:01, 61F
推
10/18 17:36, , 62F
日本那邊很多大作也都是安卓比IOS先出了，像艦娘，
10/18 17:36, 62F
→
10/18 17:36, , 63F
很明顯不再是IOS佔開發優勢
10/18 17:36, 63F
推
10/18 17:38, , 64F
IOS強在framework, 但很多遊戲開發商為了跨平台
10/18 17:38, 64F
→
10/18 17:39, , 65F
都直接建自己的framework, 所以就會有優勢了
10/18 17:39, 65F
推
10/18 23:08, , 66F
10/18 23:08, 66F
推
10/18 23:10, , 67F
安卓直接遠端ps4 為何要屈就手機遊戲 以後趨勢應該
10/18 23:10, 67F
→
10/18 23:10, , 68F
也是遠端
10/18 23:10, 68F
推
10/18 23:29, , 69F
推專業
10/18 23:29, 69F
→
10/19 00:02, , 70F
遠端PS4的app不知道SONY之外的手機能不能搞
10/19 00:02, 70F
推
10/19 00:13, , 71F
可以 我是用小米note
10/19 00:13, 71F
推
10/19 11:46, , 72F
remote play印象XDA有放修改過的版本可以在非SONY裝
10/19 11:46, 72F
→
10/19 11:46, , 73F
置上使用
10/19 11:46, 73F
‣ 更多 Angrierb 的文章
文章代碼(AID): #1M8nACvu (MobileComm)
‣ 更多 Angrierb 的文章
文章代碼(AID): #1M8nACvu (MobileComm)