Project1

标题: 云RM召唤小白鼠实验，预计月底完成基础工程。 [打印本页]

作者: 凌童鞋 时间: 2011-11-13 23:31
标题: 云RM召唤小白鼠实验，预计月底完成基础工程。
本帖最后由凌童鞋于 2011-11-14 10:45 编辑

注意，云字只是好听，请不要向云概念上自由想象啊啊…
FAQ
Q:云RM是什么呢？
A:这是一种不带浏览器外壳的WebRM......反正也是不用先下完整的游戏就可以玩的……你要理解成山寨WenRM我也不介意……
Q:那么，它到底是什么样东西的呢？
A:游戏窗口还是游戏窗口，就是可以边下边玩。也是要安装一个插件的，以便实现在网页中一键启动(如迅雷)，如果不需要这个功能也可以不安插件……(只把脚本装进去就可以了，然后图片歌曲什么的会边玩边下载……)
Q:那这个会不会开放呢？
A:当然，而且我会尽量减少修改过程，以便大家都能用上这个功能(不过10M以下的话没什么必要吧……)
大概会在除夕夜正式发布吧……(喂喂，拖的太久了吧!)
Q:其他功能呢？
A:比如在线存档，排行榜什么的都有……就是用起来麻烦点，而且第一项要求一个大空间…… 还有有什么问题直接回复，我看见就会回答……
——分割线——
召唤想第一批参加改造的小白鼠3-5只，工程不能加密(要不然我怎么编辑脚本……)，5-15M最好(空间速度超慢……)
改造最晚元旦完成(高中太苦逼了……)，尽量这个月弄出来几个…… 就是这样……
——分割线——
2011.11.13
受到 @灼眼的夏娜大人的数据包的制作、加密以及解压运行脚本的启发，直接重定义Bitmap Audio 类实现动态下载功能，应该不用像计划一样制作资源列表了。不过列表下载可以提高游戏过程中的流畅性。

作者: yangff 时间: 2011-11-13 23:56
本帖最后由 yangff 于 2011-11-14 00:09 编辑

= =有这么麻烦么？我表示这些东西实现起来就跟[HUA——]一样简单……
http://rpg.blue/forum.php?mod=vi ... 6orderby%3Dlastpost
需要我更新么？我觉得这样够了……

作者: 第七水螰 时间: 2011-11-14 00:52
不知這項工程所依賴的雲端具體是何種架構，服務是如何分配的？若是 IaaS 層的 EC2 或 PaaS 層的 Windows Azure 等商用雲端，普通用戶只怕吃不消呵。另一個問題是：雲客戶端的渲染是傳統的 Web 瀏覽器渲染模型（即本地只下載表現層數據），還是像 WebRM 那樣累積下載包括遊戲後端的完整遊戲數據，最終在本地獲得完整的一份遊戲拷貝？若是前者，那真是一個不小的工程。

一樓鏈接裏的不過是傳統的客戶-服務器模型罷了，和「雲」風馬牛不相及。

作者: Sonic1997 时间: 2011-11-14 02:37
本帖最后由 Sonic1997 于 2011-11-13 10:39 编辑

存档存到云端？还有排行榜{:nm_4:}听起来比WebRM要好。
小白鼠工程（喜欢哪个选哪个）：点击下图（造反[未脱离]，Time Controller[未完成]，史莱姆的世界[666~]
↓

作者: 马莉露丽 时间: 2011-11-14 06:10
本帖最后由马莉露丽于 2011-11-13 18:11 编辑

小白鼠来了：
6R新闻联播：http://www.66rpg.com/articles/2719
然后在这里~~诅咒抄袭的出门被车撞还得被碾死~~祝抄袭的全家掉户口本

作者: yangff 时间: 2011-11-14 20:15
本帖最后由 yangff 于 2011-11-15 00:02 编辑

第七水螰发表于 2011-11-14 00:52
不知這項工程所依賴的雲端具體是何種架構，服務是如何分配的？若是 IaaS 層的 EC2 或 PaaS 層的 Windows Az ...

我就不解释什么了，你以为WebRm是在服务器渲染的？至于存档加个存档自动上传不要9行代码。
另外“云”＝＞标题党这是公理。服务器渲染现在根本做不到，至少请期待FTTH……
另外吐槽一句“云RM”这个名字争议比较大……“66RPG云”这个项目已经有了……LZ你懂的换个霸气外露的名字吧哇哈哈哈！！
我表示这个系统真正难于实现的并非是系统而是根本没有足够的东西放上去。哎

作者: 第七水螰 时间: 2011-11-15 00:42

yangff 发表于 2011-11-14 20:15
我就不解释什么了，你以为WebRm是在服务器渲染的？至于存档加个存档自动上传不要9行代码。
另外“云”＝ ...

沒聽說過有什麼程序的表現層是在服務器端渲染的，老兄這個說法太過可笑。即便是 WWW 程序，服務器端只是傳輸相對小巧的 HTML、JavaScript、CSS 罷了，真正的渲染仍然是在客戶端。Web 瀏覽器收到代碼後，其 layout 引擎、JavaScript 引擎解析 HTML、JavaScript、CSS，並調用其底層操作系統的圖形渲染接口，實現最終的渲染。老兄若是在服務器端渲染，莫不成是直接發送圖像數據給客戶端？抱歉，如今普遍還沒有如此高速的網絡能讓用戶耐得煩。RM 當然可以做到只傳輸表現層數據，但這意味著需要定義一個新的協議，以及實現客戶端的 DSL 詞法分析器、語法分析器，工程不小於實現一個瀏覽器。當然，如果客戶端只是採用現成 HTML5 + WebGL 之類的自然又能省去不少工作。

作者: yangff 时间: 2011-11-15 18:31

第七水螰发表于 2011-11-15 00:42
沒聽說過有什麼程序的表現層是在服務器端渲染的，老兄這個說法太過可笑。即便是 WWW 程序，服務器端只是 ...

沒聽說過有什麼程序的表現層是在服務器端渲染的
不好意思真的有……
-----------------------------
老兄若是在服務器端渲染，莫不成是直接發送圖像數據給客戶端？抱歉，如今普遍還沒有如此高速的網絡能讓用戶耐得煩
所以叫你等FTTH啊。其实FTTH也不大够啦……20MB的基础速度1000MB的极限速度还是略慢，略慢。
至于传输表现层数据自然就是使用下载游戏的方式达到最大的兼容性。采用HTML5+WGL的方法移植是很麻烦的
另外你觉得游戏能有多少数据？
Ruby=>javascript
CSS+html=>UI 设定
WebGL=>Dx (ogl...)引擎。
另外你说的莫非是AJAX + REST？

毕竟游戏的交互性决定了游戏不可能像网页那样仅仅是提供一个UI了事，许多复杂的计算依然是要在客户端完成的，如果服务端返回的是
#gameXXX
:Time:1
-Picture:1
--URI:http://xxxxxxx/title.png
--x:0
--y:0
--width,height:100%
#enable mouse
这才蛋疼吧？

作者: 第七水螰 时间: 2011-11-16 10:42
本帖最后由第七水螰于 2011-11-16 10:48 编辑

yangff 发表于 2011-11-15 18:31
沒聽說過有什麼程序的表現層是在服務器端渲染的
不好意思真的有……
-----------------------------

依我看老兄似乎是把渲染的概念搞錯了，不過老兄對 multi-tier 應用程序根本的理解似乎又是正確的。渲染是指把抽象的模型轉換成具象的圖形，即是說：如果不在客戶端而在服務器端渲染，那麼抽象的程序模型在遠程端就已經被轉換為圖形了，那麼接下來只能直接把圖像數據傳輸給客戶端。只是傳輸輕量級的表現層數據（比如 HTML）給客戶端的過程不叫渲染。像 WWW 程序的渲染都是由客戶端的瀏覽器進行的。

所以叫你等FTTH啊。其实FTTH也不大够啦……20MB的基础速度1000MB的极限速度还是略慢，略慢。

奇了，我從來就沒有奢望過要在服務器端渲染，老兄要我等 FTTH 做啥？我目前用電纜用的怡然自得啊。

至于传输表现层数据自然就是使用下载游戏的方式达到最大的兼容性。采用HTML5+WGL的方法移植是很麻烦的

下載整個遊戲那就不止是表現層了，那是整個程序架構：前段表現層、邏輯層、後端數據訪問層，甚至本地引擎。採用 HTML5 + WebGL 的方法自然需要做移植的工作，但做完後對於客戶來說就是完美的平臺、客戶端獨立程序，不像基於 ActiveX 的和微軟綁定在了一起，基於 Java 的和 Oracle 綁定在了一起。

另外你觉得游戏能有多少数据？
Ruby=>javascript
CSS+html=>UI 设定
WebGL=>Dx (ogl...)引擎。

這些都是輕量級的文本數據，和直接在服務器端渲染並傳輸圖像是兩碼事好伐。別忘了我是在貶低你提出的「在服务器端渲染可行」的觀點並嘗試辨明「我以为WebRm是在服务器渲染的」是錯誤的，如果老兄也是反對「在服务器端渲染可行」這個觀點的話，這個話題便不用繼續駁了。

另外你说的莫非是AJAX + REST？

你是指「我說的」什麼？是「在服務器端渲染太過可笑」的想法，還是「定義一個新的協議，以及實現客戶端的 DSL 詞法分析器、語法分析器」？前者壓根和 Ajax、REST 和兩個層面的概念。至於後者，如果客戶端是 Web 瀏覽器，那麼部分協議內容自然可以利用 Ajax 實現；而在遊戲是面向服務架構（SOA）的場合下或許也能利用到 REST API，但這只是工具的選擇問題，用別的工具照樣能實現不同的協議但相同的通信內容。或許對於一個簡單的遊戲來說，服務器端不需要傳輸太複雜的數據給客戶端，那麼自然也不會出現像 HTML、JavaScript、CSS 這樣的相對複雜的 DSL，自然也就不需要客戶端實現專門針對這些 DSL 的詞法分析、語法分析器以及類似 Web 瀏覽器的 layout 引擎了。

毕竟游戏的交互性决定了游戏不可能像网页那样仅仅是提供一个UI了事，许多复杂的计算依然是要在客户端完成的

和圖形渲染有關的計算自然須得在客戶端進行，感謝支持我的論點 :)

作者: yangff 时间: 2011-11-16 18:13

第七水螰发表于 2011-11-16 10:42
依我看老兄似乎是把渲染的概念搞錯了，不過老兄對 multi-tier 應用程序根本的理解似乎又是正確的。渲染是 ...

图形计算必然在本地执行，不过将逻辑运算与图形分离真是个好办法……这样可以做的事情多了，我试试看能不能做到吧！
另外我上面那个回帖顺序有点乱:L所以感觉有点奇怪……
另外即便如此我觉得用云计算为基础提供在线的逻辑运算依旧不大现实（集体表现为只需要一个几百K不到的客户端就可以进行游戏，而游戏西园则像网页那样换缓存，不再有存档读档只说，只需要登陆账号随时从上次结束的地方开始游戏……），并且对于加密技术来说确实是一个很好的解决方案……那么最大的问题反倒是服务器运算的速度了（网速要求不高的ping值能到10就够了，另外电信在4年回在主城完成光纤到街，10年内完成光纤到户，使用一些绝大多数的云都可以达到这个速度的……

正在 Ping easyjudge.sinaeae.com [218.85.148.250] 具有 32 字节的数据:
来自 218.85.148.250 的回复: 字节=32 时间=7ms TTL=57
来自 218.85.148.250 的回复: 字节=32 时间=7ms TTL=57
来自 218.85.148.250 的回复: 字节=32 时间=7ms TTL=57
来自 218.85.148.250 的回复: 字节=32 时间=7ms TTL=57

218.85.148.250 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 7ms，最长 = 7ms，平均 = 7ms

）图像数据从HTTP通道走，游戏数据从UDP走。！
而且更新游戏也方便很多。
不过比较严重的一个问题倒是跨地域的使用以及……云按CPU时间计费……

作者: 第七水螰 时间: 2011-11-17 10:06

yangff 发表于 2011-11-16 18:13
图形计算必然在本地执行，不过将逻辑运算与图形分离真是个好办法……这样可以做的事情多了，我试试看能不 ...

怎麼個不現實法？這種需要網絡通信支援的“單機（單玩家）遊戲”，數據量再大也大不過網絡遊戲，而專業的雲服務提供商效率通常都是高於單純的集群數據中心的。分佈管理的雲計算服務可以輕易逼近無限可伸縮性，而數據中心往往會有各種技術問題。從部署難度來看，雲服務的易用性也是遠勝數據中心。使用雲服務唯一的缺點就是對底層硬件沒有控制權，IaaS 提供商最多提供用戶空間的一些接口，依賴於內核空間的應用程序就和雲無緣了。

那么最大的问题反倒是服务器运算的速度了

（網絡遊戲）數據中心能達到的運算速度，雲同樣也能達到，而且吞吐量只有更大。可能數據中心的唯一優勢就是當用戶群體僅限於 LAN 內部或極其靠近 CDN 中心的 WAN 區域時效率略優於雲，比如 Intranet。

[...] 对于加密技术来说确实是一个很好的解决方案……

哪方面的加密？客戶端的資源無論如何都有一部分資是暴露在破解技術之下的（2D 背景、模型、紋理、視頻、音頻等）。如今的計算機還沒發展到所有一切都實時渲染的地步，很多資源仍然需要通過遊戲開發方預先離綫渲染，並預先或在需要時傳輸給客戶端。在遠程端保護邏輯層的好處是遊戲只能這麼進行，玩家不能隨意修改流程，以及不會出現單純的盜版複製品。

网速要求不高的ping值能到10就够了，另外电信在4年回在主城完成光纤到街，10年内完成光纤到户，使用一些绝大多数的云都可以达到这个速度的……

哪有這麼誇張，目前一般的網絡遊戲只要維持在 100ms 以內延遲就可以很流暢了，還不提單人在綫遊戲數據量遠遠小於多人在綫遊戲。莫非你還在糾結“在服務器端渲染”這茬？= =

图像数据从HTTP通道走，游戏数据从UDP走。

HTTP 只是一個現成的能良好契合 WWW 通信的應用層協議，如果客戶端不是 Web 瀏覽器就沒必要用 HTTP 了，處理普通的二進制數據時如需可靠性，那純 TCP/IP 便足矣。遊戲數據的傳輸也分類型，在實時環境（動作遊戲）中高速變化的狀態、輸入等數據只需要最新的一份而不需要考慮先前丟失的數據包，那麼 UDP 自然是最好的選擇；對於可靠性優先的數據，或是對傳輸效率要求不高的數據（很多非動作遊戲），那仍然需要某種面向連接的協議。當然，這個協議不能單純的用 TCP，TCP 和 UDP 在一個實時環境下併發使用會加劇 UDP 丟包的。如今大部分遊戲都是將 TCP 中需要的（面向连接、驗證）的部分單獨實現而拋棄某些明顯的經費（TCP 數據包隊列），並與 UDP 一同組成一個自定義的傳輸層協議。

作者: 凌童鞋 时间: 2011-11-17 10:53
我说，这怎么变成辩论贴了？我的东西的目的就是为了像webrm那样，下一个1M左右的插件就可以不用等全下完后再玩大的游戏，虽然运算是在本机，但现在有转不动RM的电脑吗…我起个名不行吗？为什么云非要是云概念的东西？云只是一个汉字而已！

作者: yangff 时间: 2011-11-17 18:55

第七水螰发表于 2011-11-17 10:06
怎麼個不現實法？這種需要網絡通信支援的“單機（單玩家）遊戲”，數據量再大也大不過網絡遊戲，而專業的 ...

通过一个好的设计确实ping值在100ms内可以防延迟，但是考虑60的fps，最好还是有个比较优秀的ping值，1000ms/60约=16，不过倒不是一定要每桢刷新，但是看这个算法怎么设计了，设计的好了就不需要很高的ping，设计的不好就悲剧了！
至于传输协议UDP虽然是不错的选择但是RM显然不支持这可能比较麻烦（不过不严重）……另外之所以选择HTTP协议主要还是考虑到2进制数据不比桢数据，有较长的载入时间同时精度要求也略高。
至于加密自然就是你所说的这部分，至于图像的加密不再考虑范围内，你再怎么加密我也能截图啊=v=
所谓的不现实是说现在，包括云的接口还有中国的网络质量这些问题。
另外网络游戏其实把更多的东西分派到了客户端……不过无所谓即使了网游能做单机也能做，只不过比较麻烦就是了！

作者: 雷欧纳德 时间: 2011-11-17 21:17
边下边玩并不是难点，只是webRM中的一部分功能
webRM没有大规模投入使用的问题在于，我们根本不敢开放一个体积超过10M的游戏提供边下边玩
因为一旦开放6r的三台服务器100m独享带宽将立刻满负荷崩溃

作者: 絀神入化 时间: 2011-11-17 21:23
不太明白LZ在说什么
WEBRM= =？

作者: yangff 时间: 2011-11-17 21:27
本帖最后由 yangff 于 2011-11-17 21:29 编辑

雷欧纳德发表于 2011-11-17 21:17
边下边玩并不是难点，只是webRM中的一部分功能
webRM没有大规模投入使用的问题在于，我们根本不敢开放一个 ...

所以说需要CDN节点服务器和P2P网络，前者显然不是6R消费得起的，后者稳定性欠佳……但是这说明什么问题呢？
同样的游戏，你给人家在线玩一下子带宽占光，提供下载，带宽毫无压力，说明这个方向还是有潜力的啊！

现在也许不行，但是以后呢？

作者: 雷欧纳德 时间: 2011-11-17 21:39

yangff 发表于 2011-11-17 21:27
所以说需要CDN节点服务器和P2P网络，前者显然不是6R消费得起的，后者稳定性欠佳……但是这说明什么问题呢 ...

如果投入的带宽能够获得等额的回报（金钱回报 or 流量回报 or 广告收益），即实现网页游戏的运营模式，那么就可以大规模投入推广（加服务器和带宽，说穿了就是砸钱的问题）

作者: 凌童鞋 时间: 2011-11-17 21:46
……无奈了，我难道真要开那个复杂计划？
设计一种单文件封装格式，利用断点续传技术的变向应用，实现用网盘当空间，来解决服务器问题？
这是多么苦逼的设计啊…虽然本打算慢慢研究这个的…

凌童鞋于2011-11-17 21:53补充以下内容：
算了，还是明说吧…手机不方便拆两贴不介意吧？
断点续传其实就是告诉服务器从指定位置开始传输数据，对吧？
所以如果将资源合并在一起只要知道资源索引就可以下载了，是吧？
然后就是这样，打包时带一份索引表，根据需求下载指定位置的资源。
当然这只是理论，实现还是有些难度的。

作者: yangff 时间: 2011-11-17 22:00

雷欧纳德发表于 2011-11-17 21:39
如果投入的带宽能够获得等额的回报（金钱回报 or 流量回报 or 广告收益），即实现网页游戏的运营模式，那 ...

简单的来说就是这样，不过毕竟没有严格的统计数据可以论证这点，到底会有多少人愿意在网页上进行游戏并为之付费、投放广告……反正中国这种人肯定不多。而且如果大规模拖放的话赢利点绝对不在游戏收费上……整个架设起来简直像架设网游的服务器组，没有足够的玩家哪里支撑得起。不过如果是2D的话按照现在中国网络建设的速度还是有希望（低成本）的……
或者可以试试象这样真用带宽小的？
http://www.xyz-soft.com/
另外真心觉得中国的单机游戏实在是……不是一个好的市场啊……

作者: 凌童鞋 时间: 2011-11-17 22:08
现在国内玩网游的太多，玩单机的太少。玩rm做出来的游戏的人更少。而且精品的太少，小型的只够娱乐一下，大型的还有可能推销出去但是无法做到盈利。最好的方法是置入广告但是这会影响玩家对游戏的体验。而且做出来的游戏一般也没什么宣传途径。

作者: yangff 时间: 2011-11-17 22:10
本帖最后由 yangff 于 2011-11-17 22:11 编辑

凌童鞋发表于 2011-11-17 22:08
现在国内玩网游的太多，玩单机的太少。玩rm做出来的游戏的人更少。而且精品的太少，小型的只够娱乐一下，大 ...

如果6R能够成为Steam那样的平台那真是造福后代了……呵呵
另外Rm不是重点，无论是RM还是什么要求都只有一个傻瓜化……于是……
但是……
傻瓜=非专业=“为了部落！” =伸手=赢利不能
如果是专业
专业=复杂=不会用=专业用户不屑于用=没有用户=赢利不能
就是这个问题

欢迎光临 Project1 (https://rpg.blue/)