[請益] Html5手遊潮流(?)

看板GameDesign (遊戲設計)作者 (finally1999)時間9年前 (2015/10/31 23:36), 編輯推噓15(15041)
留言56則, 14人參與, 最新討論串1/3 (看更多)
最近某點數卡某APP在內部可以執行H5的手遊 不是休閒的那種 算是中、大型RPG的卡牌遊戲 (IP是知名網遊小說改編的 *這樣應該不算打廣告吧XD) 主要就是說 現在手機的H5遊戲時代...難道要來臨了? 不過IOS好像沒辦法玩(沒有在上架的APP內,可能是金流介接的關係...吧?) 這塊H5遊戲應該會是這家公司重點發展 大概之後在那APP能玩到很多H5 至於大家應該也都知道目前許多Flash都轉成H5了 (直播網站twitch、youtube) 而現在很多web game也都走向H5 不用載元件也不用裝flash都能直接玩 主要做成響應式的話手機也能直接開(不同介面) 等同於有瀏覽器就可以玩 我上面講的那遊戲 在手機上玩起來都是算十分順暢的 *目前知名的H5引擎應該就是白鷺吧 可以去論壇看 很多自製H5小品 不知道下一代遊戲製作的潮流會不會往H5這個方向走呢(?) 各位前輩怎麼看 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.228.151.242 ※ 文章網址: https://www.ptt.cc/bbs/GameDesign/M.1446305761.A.4DE.html

11/01 02:22, , 1F
金流麻煩
11/01 02:22, 1F

11/01 03:45, , 2F
如果只單做台灣市場,是否還有金流麻煩的問題?
11/01 03:45, 2F

11/01 03:46, , 3F
又若以中國那的開發者,僅作他們內需市場,是否有金流麻煩?
11/01 03:46, 3F

11/01 07:12, , 4F
unity可以跨pc到psv到xbox,靈活度感覺更高,手機三大
11/01 07:12, 4F

11/01 07:12, , 5F
平台轉換也很輕鬆
11/01 07:12, 5F

11/01 07:21, , 6F
我爬了下文,對岸偏好的好像是cocos2d-js框架,反正不
11/01 07:21, 6F

11/01 07:21, , 7F
管如何能以最低投入產生最大報酬的引擎或框架就會自然
11/01 07:21, 7F

11/01 07:21, , 8F
紅起來啦
11/01 07:21, 8F

11/01 08:36, , 9F
從玩家端而言,我懷疑不用安裝這點有多少優勢,畢竟資料
11/01 08:36, 9F

11/01 08:36, , 10F
還是要下載。除此之外html5還有其他優勢嗎?如果沒有,通
11/01 08:36, 10F

11/01 08:36, , 11F
常大者恆大
11/01 08:36, 11F

11/01 11:59, , 12F
但是program 你們老闆看新聞覺得html5很威啊
11/01 11:59, 12F

11/01 12:00, , 13F
programer
11/01 12:00, 13F

11/01 12:35, , 14F
JS的語法很過時
11/01 12:35, 14F

11/01 12:37, , 15F
直譯式語言和編譯式執行效能也差太多
11/01 12:37, 15F

11/01 13:12, , 16F
js語法過時... es6表示:
11/01 13:12, 16F

11/01 13:50, , 17F
只能說效能極差 大概就偏比較靜態的遊戲吧?
11/01 13:50, 17F

11/01 13:53, , 18F
就算效能差,不代表每個遊戲都會直衝效能瓶頸
11/01 13:53, 18F

11/01 13:53, , 19F
能夠有好遊戲支撐開發生態才是最重要的
11/01 13:53, 19F

11/01 14:34, , 20F
效能極差…?跟c比是不用說比較慢啦,但跟java之類比,
11/01 14:34, 20F

11/01 14:34, , 21F
並沒有差到哪去啊,你的資訊有點過時了
11/01 14:34, 21F

11/01 17:05, , 22F
遊戲內容才是重點+1
11/01 17:05, 22F

11/01 17:59, , 23F
js光是沒有執行序這一點就被巴死了啦.... = =
11/01 17:59, 23F

11/01 18:01, , 24F
還有,java在server方面的處理能力,是可以做到接近c的。
11/01 18:01, 24F

11/01 18:02, , 25F
因為jvm會依照程式片段的使用頻率,把常用的區塊編譯為機
11/01 18:02, 25F

11/01 18:02, , 26F
械碼後再去執行。
11/01 18:02, 26F

11/01 18:49, , 27F
js 沒那麼不堪
11/01 18:49, 27F

11/01 19:35, , 28F
js沒有執行緒這點你也delay了,早就有web worker了
11/01 19:35, 28F

11/01 19:37, , 29F
另外js也早就有JIT了,無論是firefox或chrome都有實作
11/01 19:37, 29F

11/01 19:37, , 30F
至於java接近c...你把java想得太美好了吧,java的記憶體
11/01 19:37, 30F

11/01 19:38, , 31F
使用效率爛透了
11/01 19:38, 31F

11/01 19:41, , 32F
雖然js也差不多糟就是了
11/01 19:41, 32F

11/01 20:28, , 33F
webworker不算執行緒 js沒辦法同時處理繪圖跟計算
11/01 20:28, 33F

11/01 20:30, , 34F
webworker算是另外開個「域」出來去跑一些東西而已,但兩
11/01 20:30, 34F

11/01 20:31, , 35F
邊的資料等於是copy過去用的。如果有執行緒,你會看到js出
11/01 20:31, 35F

11/01 20:35, , 36F
現synchronize lock的功能,而且可以同時出現alert又變動
11/01 20:35, 36F

11/01 20:35, , 37F
dom物件
11/01 20:35, 37F

11/01 20:39, , 38F
還有 js 本身是弱型別動態語言,這是語言先天設計上的問題
11/01 20:39, 38F

11/01 20:39, , 39F
,這種設計方式是為了寫程式方便,但犧牲的就是效能,只是
11/01 20:39, 39F

11/01 20:40, , 40F
在現在的硬體上犧牲掉的效能可忽略。怎麼就這樣把JS捧上天
11/01 20:40, 40F

11/01 20:42, , 41F
了?
11/01 20:42, 41F

11/01 20:52, , 42F
但你講的話依舊是錯的阿快,我從來沒說過他比java快阿
11/01 20:52, 42F

11/01 20:52, , 43F
他本來就有上限,但你說他很慢是個天大的錯誤阿
11/01 20:52, 43F

11/01 20:53, , 44F
`自從瀏覽器大戰後,js的速度是一年比一年快阿
11/01 20:53, 44F

11/01 20:54, , 45F
比c慢是一定的,但跟java比輸贏還很難說
11/01 20:54, 45F

11/01 20:55, , 46F
來比比看就知道了,我兩邊都會寫
11/01 20:55, 46F

11/01 20:56, , 47F
裡沒辦法同時處裡繪圖跟計算也很難說,雖然目前沒有實作
11/01 20:56, 47F

11/01 20:57, , 48F
但是w3c的spec中是有繪圖在web worker中這一塊的
11/01 20:57, 48F

11/01 21:18, , 49F
另外,你說所有的資料都是copy過去的,那依舊是錯的
11/01 21:18, 49F

11/01 21:19, , 50F
資料室可以在不同worker共用的,只是不能同時用
11/01 21:19, 50F

11/01 23:05, , 51F
我還蠻好奇的,javascript是怎麼保證「不能同時用」的?
11/01 23:05, 51F

11/01 23:05, , 52F
一般程式中是交給 synchronize 或是 lock 去處理這種問題
11/01 23:05, 52F

11/02 22:31, , 53F
我記得Web Worker應該不是直接去動資料,而是運算完後
11/02 22:31, 53F

11/02 22:32, , 54F
傳回來主程式,再由主程式去改那個資料,所以可以避免
11/02 22:32, 54F

11/02 22:32, , 55F
動到同一個資料的問題,不過這樣會有覆蓋的問題就是
11/02 22:32, 55F

11/02 22:33, , 56F
畢竟Web Worker那邊是有明確規定不准直接動DOM
11/02 22:33, 56F
文章代碼(AID): #1MDD_XJU (GameDesign)
文章代碼(AID): #1MDD_XJU (GameDesign)