云RM召唤小白鼠实验，预计月底完成基础工程。

凌童鞋

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

yangff

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

第七水螰

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

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

Sonic1997

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

马莉露丽

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

yangff

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

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

第七水螰

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 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
这才蛋疼吧？

第七水螰

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 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时间计费……