| 赞 | 0 |
| VIP | 0 |
| 好人卡 | 0 |
| 积分 | 1 |
| 经验 | 54280 |
| 最后登录 | 2006-1-29 |
| 在线时间 | 0 小时 |
Lv1.梦旅人 (禁止发言)
- 梦石
- 0
- 星屑
- 50
- 在线时间
- 0 小时
- 注册时间
- 2005-10-22
- 帖子
- 81
|
这串回帖里面哪里有诋毁RM的文字呢？好像还没有。大家都沉浸在喜悦之中～
LZ的帖子以这样的内容开头，然后YY下去……
其实所有的商业游戏跟RMXP的制作方法和流程一模一样
不觉得这话说的比较过了么？RMXP的发展程度是令人欣喜的，每个RMer都在努力。但是，有一点成果后就高兴的忘乎所以，这不是什么好事情。
突然想给浇盆冷水，下面的文字不喜勿看。认为不对可以指出～～
我不理解究竟楼主得到什么真传才发出这样的豪言壮语。但是很明显，楼主犯了两个错误：
1、游戏（包括商业非商业）并不都是用像RM这样方便的东西做出来的。你能从RM游戏的开发过程中体会到的，也不过是作坊游戏开发的一种很传统的模式而已。那么这种方式有价值么？这个只有自己把握了……
2、RM功能虽然强大，甚至使用了Ruby这种高级脚本语言，使得扩展很方便。但是，我要说，它的限制依旧很多。使用RGSS，即使是开发2D的游戏（注意不是日式RPG这一种，而是广义的游戏），开发起来依旧是困难重重。
为什么这么说呢？我了解的很少，只能粗浅的分析一下：
======================================================================
抛开那个可视化的编辑器以及其相关的数据结构，为了满足开发一个基本的游戏的需求，RGSS提供了三个模块：
【Audio、Graphics、Input】
Input部分，RGSS提供的功能算是中规中矩，因为还可以通过API扩展，而且大部分游戏对此没有十分特殊的要求，所以这一块不是限制。
Audio部分，RGSS提供了对多种音频文件的支持，但是也仅此而已。音乐音效只是播放、停止、淡出么？或许RPG玩家对此没有它求，可是实际游戏中对于声音的要求是多方面的。因为自己不是专家，不多说，想了解的，可以私下讨论。
鉴于勤能补拙的说法，某些效果也可以通过其他方式实现，而且大部分游戏没有频繁的音频播放，这个Audio模块足够满足大部分需要了，我也不认为它是限制。
Graphics模块……好的，RGSS最精彩的部分来了。突然想到，现在很流行引擎这个词，很多人也喜欢研究这个东西。Graphics就是RGSS的图像引擎。这个图像引擎很不错，结构层次清晰，使用起来很简单。而且，功能也不俗，直接支持32bit的图像伸拉旋转变型等处理。
功能是不错……但是……性能呢？32bit色，对于2D游戏图像来说，这是个很大的开销。Graphics里面的每一幅图片都是32bit的图像，多么大的浪费啊！！首先内存消耗巨大，再者，每次的图像显示都需要进行Alpha混合，这个开销，注定了它将成为整个环节的瓶颈。
======================================================================
我们离开底层模块的讨论，RMXP提供了高层的开发环境，使用Ruby语言来进行实际的游戏逻辑实现。那么，第二个瓶颈来了，它就是：Ruby
Ruby是个不错的东西，面向对象，而且是动态的脚本语言，这使得Ruby异常灵活。然而，这也是它的问题，Ruby注定是个低速的东西。脚本语言本身已经是建立在脚本解释基础上的，速度较其他编译执行的语言慢了一拍。而Ruby的动态特性又导致它不能像大部分脚本语言一样，先被编译成字节码，只能以字符串的形式，被逐字解释执行。这是非常可怕的开销……
======================================================================
接下来，我们继续上浮，离开Ruby这个层面的讨论，直接来探讨RGSS本身实现的游戏逻辑。
这个游戏逻辑构思的十分巧妙，具体怎么巧妙，大家自己来赞美吧。目前很多RMer都在做这样的工作，在努力的加强和改造这套游戏逻辑，而且取得了很多成果，这都是十分令人钦佩的事情。
但是，这个游戏逻辑是为RMXP服务的……不得不说，它和RMXP的可视化编辑器接合的十分紧密。想抛开这个游戏结构，重新打造一个游戏，那么就要面对大量的脚本书写工作。
可能那些脚本粘贴者要觉得奇怪了：“很多脚本拿来套一套，我的游戏就变样子了呀”那么请注意，粘贴者不是开发者。开发者所作的工作，比粘贴要复杂的多。越是功能强大的改造脚本，背后的脚本书写工作量就越大。其繁琐程度已经不亚于建立在其他工具上的游戏开发。关键还有一点，不同的脚本之间，往往不能共存。这是Ruby的动态特性搞得鬼……再加上RMXP本身的游戏逻辑也限制了大家完全自由的发挥，某些改造必然要造成冲突，这是RMXP的又一个限制。
======================================================================
以上虽然字多，但都是很粗浅的分析，个人水平所限也只能说到这个程度。
RGSS的开发人员都是比我高明很多的专业人士，他们必然了解这些问题的。但是他们就这样做了……那么，我们就需要问：为什么？
为什么那？我所说的那些限制，都是一个高效的2D游戏引擎所应该避免的问题。RMXP的定位恰恰不是一个高效的2D游戏引擎，所以它根本不需要考虑这个问题。
RM的定位是什么？是商业化？是专业性？或者是游戏性？我觉得不是这样，它倡导的是娱乐性！是参与性！是让大家体会到动手的乐趣！
好吧，一定有人还在念念不忘RM的每一个令人惊异进步，网络化……鼠标……各种看似不可能的事情，都被一一“突破”了。这些又能证明什么呢？证明RM已经具备了其他游戏引擎或者工具的全部要素？证明了只要RM在，“一切皆有可能”？拜托，那只不过是证明了RM具有很好的扩展性……扩展出来的东西其实用性已经在另外一个层面了。不客气的说出一个事实，目前搞出来的很多东西并没有实用价值，大家只是研究的开心而已。或者说，搞的是“事倍功半”的东西，也就事虽然做出来了，但是做的并不漂亮。
开发一个对得起用户的商业化作品，需要什么功能就必须实现什么功能，不仅仅是意思意思，像个样子就足够的。RM的种种限制使得它不能做好全部的事情～
RM的确挺好玩，而且也绝对有钻研价值。但是，千万不要以为了解了RM就了解了全部……也不要以为RM就是无敌的……希望有人能够明白。
再PS一下：上面扯什么RM能不能做商业游戏的人，有谁说“RM不能做商业游戏”咯？……商业游戏就是卖钱的游戏……什么东西都能做来卖钱，有什么好讨论的。 |
|
楼主: 忧郁
[复制链接]
写轮眼
发表于 2006-1-23 20:59:22