作者finally1999 (finally1999)
看板GameDesign
标题[请益] Html5手游潮流(?)
时间Sat Oct 31 23:35:58 2015
最近某点数卡某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://webptt.com/cn.aspx?n=bbs/GameDesign/M.1446305761.A.4DE.html
1F：推 littleshan: 金流麻烦 11/01 02:22
2F：推 goury: 如果只单做台湾市场，是否还有金流麻烦的问题？ 11/01 03:45
3F：→ goury: 又若以中国那的开发者，仅作他们内需市场，是否有金流麻烦? 11/01 03:46
4F：推 lzainside: unity可以跨pc到psv到xbox，灵活度感觉更高，手机三大 11/01 07:12
5F：→ lzainside: 平台转换也很轻松 11/01 07:12
6F：→ lzainside: 我爬了下文，对岸偏好的好像是cocos2d-js框架，反正不 11/01 07:21
7F：→ lzainside: 管如何能以最低投入产生最大报酬的引擎或框架就会自然 11/01 07:21
8F：→ lzainside: 红起来啦 11/01 07:21
9F：推 tst5381: 从玩家端而言，我怀疑不用安装这点有多少优势，毕竟资料 11/01 08:36
10F：→ tst5381: 还是要下载。除此之外html5还有其他优势吗？如果没有，通 11/01 08:36
11F：→ tst5381: 常大者恒大 11/01 08:36
12F：→ hodsala: 但是program 你们老板看新闻觉得html5很威啊 11/01 11:59
13F：→ hodsala: programer 11/01 12:00
14F：→ wt5566: JS的语法很过时 11/01 12:35
15F：→ wt5566: 直译式语言和编译式执行效能也差太多 11/01 12:37
16F：推 asoedarren: js语法过时... es6表示: 11/01 13:12
17F：推 he103958: 只能说效能极差 大概就偏比较静态的游戏吧? 11/01 13:50
18F：推 cjcat2266: 就算效能差，不代表每个游戏都会直冲效能瓶颈 11/01 13:53
19F：→ cjcat2266: 能够有好游戏支撑开发生态才是最重要的 11/01 13:53
20F：推 mmis1000: 效能极差…？跟c比是不用说比较慢啦，但跟java之类比， 11/01 14:34
21F：→ mmis1000: 并没有差到哪去啊，你的资讯有点过时了 11/01 14:34
22F：推 waldfantasy: 游戏内容才是重点+1 11/01 17:05
23F：推 LaPass: js光是没有执行序这一点就被巴死了啦.... = = 11/01 17:59
24F：→ LaPass: 还有，java在server方面的处理能力，是可以做到接近c的。 11/01 18:01
25F：→ LaPass: 因为jvm会依照程式片段的使用频率，把常用的区块编译为机 11/01 18:02
26F：→ LaPass: 械码後再去执行。 11/01 18:02
27F：→ johnny94: js 没那麽不堪 11/01 18:49
28F：→ mmis1000: js没有执行绪这点你也delay了，早就有web worker了 11/01 19:35
29F：→ mmis1000: 另外js也早就有JIT了，无论是firefox或chrome都有实作 11/01 19:37
30F：→ mmis1000: 至於java接近c...你把java想得太美好了吧，java的记忆体 11/01 19:37
31F：→ mmis1000: 使用效率烂透了 11/01 19:38
32F：→ mmis1000: 虽然js也差不多糟就是了 11/01 19:41
33F：推 LaPass: webworker不算执行绪 js没办法同时处理绘图跟计算 11/01 20:28
34F：→ LaPass: webworker算是另外开个「域」出来去跑一些东西而已，但两 11/01 20:30
35F：→ LaPass: 边的资料等於是copy过去用的。如果有执行绪，你会看到js出 11/01 20:31
36F：→ LaPass: 现synchronize lock的功能，而且可以同时出现alert又变动 11/01 20:35
37F：→ LaPass: dom物件 11/01 20:35
38F：推 LaPass: 还有 js 本身是弱型别动态语言，这是语言先天设计上的问题 11/01 20:39
39F：→ LaPass: ，这种设计方式是为了写程式方便，但牺牲的就是效能，只是 11/01 20:39
40F：→ LaPass: 在现在的硬体上牺牲掉的效能可忽略。怎麽就这样把JS捧上天 11/01 20:40
41F：→ LaPass: 了？ 11/01 20:42
42F：→ mmis1000: 但你讲的话依旧是错的阿快，我从来没说过他比java快阿 11/01 20:52
43F：→ mmis1000: 他本来就有上限，但你说他很慢是个天大的错误阿 11/01 20:52
44F：→ mmis1000: `自从浏览器大战後，js的速度是一年比一年快阿 11/01 20:53
45F：→ mmis1000: 比c慢是一定的，但跟java比输赢还很难说 11/01 20:54
46F：推 LaPass: 来比比看就知道了，我两边都会写 11/01 20:55
47F：→ mmis1000: 里没办法同时处里绘图跟计算也很难说，虽然目前没有实作 11/01 20:56
48F：→ mmis1000: 但是w3c的spec中是有绘图在web worker中这一块的 11/01 20:57
49F：→ mmis1000: 另外，你说所有的资料都是copy过去的，那依旧是错的 11/01 21:18
50F：→ mmis1000: 资料室可以在不同worker共用的，只是不能同时用 11/01 21:19
51F：推 LaPass: 我还蛮好奇的，javascript是怎麽保证「不能同时用」的？ 11/01 23:05
52F：→ LaPass: 一般程式中是交给 synchronize 或是 lock 去处理这种问题 11/01 23:05
53F：推 hoyunxian: 我记得Web Worker应该不是直接去动资料，而是运算完後 11/02 22:31
54F：→ hoyunxian: 传回来主程式，再由主程式去改那个资料，所以可以避免 11/02 22:32
55F：→ hoyunxian: 动到同一个资料的问题，不过这样会有覆盖的问题就是 11/02 22:32
56F：→ hoyunxian: 毕竟Web Worker那边是有明确规定不准直接动DOM 11/02 22:33