新手教程--从0开始学RGSS2(2013-09-21 修复索引地址)

亿万星辰 · 发表于 2011-2-19 11:47:33

本帖最后由亿万星辰于 2011-2-19 11:49 编辑

图里说的修改是指修改oxoy坐标

其实你设置x=0,y=0这样的操作时，是以那个红点为基准，拽着整个sprite跑来跑去……

铃仙·优昙华院·因幡 · 发表于 2011-2-23 23:10:51

Font 字型和 Table 表格

Font 字型

   Font 的作用也大. 一切需要显示文字的地方都是有它的身影. Font 通常是当做 Bitamp 的属性之一和 Bitmap 一起使用. Font 的属性如下:

   size
   设定字体大小, 默认值是 20. 如果需要用到大点的文字的话, 可以修改. 比如

s = Sprite.new
s.x = 0
s.y = 0
s.bitmap = Bitmap.new(544, 416)
s.bitmap.draw_text(0, 0, 400, 100, "字号20: 铃仙·优昙华院·因幡")
s.bitmap.font.size = 30
s.bitmap.draw_text(0, 50, 400, 100, "字号30: 铃仙·优昙华院·因幡")

复制代码

运行就是这样:

bold
是否设定成粗体. true 为使用粗体. 默认是 false, 也就是不使用.

s = Sprite.new
s.x = 0
s.y = 0
s.bitmap = Bitmap.new(544, 416)
s.bitmap.draw_text(0, 0, 400, 100, "普通: 铃仙·优昙华院·因幡")
s.bitmap.font.bold = true
s.bitmap.draw_text(0, 50, 400, 100, "粗体: 铃仙·优昙华院·因幡")

复制代码

italic
是否设定成斜体. 默认是 false, 不使用

s = Sprite.new
s.x = 0
s.y = 0
s.bitmap = Bitmap.new(544, 416)
s.bitmap.draw_text(0, 0, 400, 100, "普通: 铃仙·优昙华院·因幡")
s.bitmap.font.italic = true
s.bitmap.draw_text(0, 50, 400, 100, "斜体: 铃仙·优昙华院·因幡")

复制代码

color
设定文字的颜色, 为 Color 类的实例

s = Sprite.new
s.x = 0
s.y = 0
s.bitmap = Bitmap.new(544, 416)
s.bitmap.draw_text(0, 0, 400, 100, "默认颜色: 铃仙·优昙华院·因幡")
s.bitmap.font.color = Color.new(244, 11, 209)
s.bitmap.draw_text(0, 50, 400, 100, "有颜色: 铃仙·优昙华院·因幡")

复制代码

shadow
设定字体阴影, 注意的是, 阴影是黑色的, 而且不能修改.默认是使用的, 也就是 ture

s = Sprite.new
s.x = 0
s.y = 0
s.bitmap = Bitmap.new(544, 416)
s.bitmap.fill_rect(0, 0, 544, 416, Color.new(255, 255, 255))
s.bitmap.font.color = Color.new(544, 11, 206)
s.bitmap.font.shadow = false
s.bitmap.draw_text(0, 0, 400, 100, "无阴影: 铃仙·优昙华院·因幡")
s.bitmap.font.shadow = true
s.bitmap.draw_text(0, 50, 400, 100, "有阴影: 铃仙·优昙华院·因幡")

复制代码

    default_name default_size default_bold default_italic default_shadow default_color
   设定字体相关属性的默认值, 分别是字体名, 字体大小, 粗体标志, 斜体标志, 阴影标志, 颜色标志. 用法和以上的一样. 只是修改这些值, 影响的是整个 VX 的全部字体的默认值.

Table 表格

感觉没啥好说的. 只是在处理多个数据的时候, 处理效率比数组(Array) 要高. 其他的个人感觉没有 Array 好用. 属性什么的, 看 F1 的可以了. (偷懒一下 > <)

禾西 · 发表于 2011-3-2 07:14:14

本帖最后由禾西于 2011-3-3 11:23 编辑

werhsqgl · 发表于 2011-3-11 16:25:52

数月不见，紫大人依然是风采依旧啊

zh99998 · 发表于 2011-3-18 08:54:18

回复八云紫的帖子

主人SAMA该更新Spriteset咯

爱丽丝·玛格特罗依德 · 发表于 2011-3-20 20:22:25

本帖最后由爱丽丝·玛格特罗依德于 2011-3-20 20:23 编辑

Sprite 和 Spriteset 类集

Sprite_XXX
   Sprite 的本意是精灵的意思, 也可以理解成显示图片的相框. 那么 Sprite_XXX 的类也就是用来显示而定义使用的. 也就是说, VX 的全部显示画面都是由这个类集来完成.

   1. Sprite_Base
   所有 Sprite_XXX 类的父类. Sprite_Base 继承于 Sprite . 从这里可以看出 Sprite_Base 和其子类都是用来显示的.
   查看 Sprite_Base 的定义可以看到一个陌生的变量定义. @@XXX 变量.
         @@XXX
         @@ 开头的变量叫做类变量(其实我更喜欢叫静态变量). 这类的变量有个特点. 也就是说类变量是这个类的实例都共同拥有以及共享的变量.
   例子:

class A
attr_accessor :b
@@a = 1
def initialize(n)
@b = n
end
def a
return @@a
end
def a=(n)
@@a = n
end
end
a1 = A.new("a1")
a2 = A.new("a2")
p "a1.a = #{a1.a}" #=> a1.a = 1
p "a1.b = #{a1.b}" #=> a1.b = a1
a2.a = "a3"
a2.b = "a3"
p "a1.a = #{a1.a}" #=> a1.a = a3
p "a1.b = #{a1.b}" #=> a1.b = a1

复制代码

从例子可以看出 @@ 变量的特点的说. 我们从 a2 那里修改了 @@a 的值, 都是 a1 中的值也发生了改变.

   回到 Sprite_Base .  Sprite_Base 最主要的作用是显示动画.

   2. Sprite_Character
   用于显示行走图的精灵类. 这里包括所有的行走图, 心情. 如果我们把某事件的行走图改成使用图块来显示的话, 显示部分也是这个类的创建的.

   3. Sprite_Battler
   显示战斗者图片的精灵类. 当然, 在默认的脚本的前提下, 这个类是专门给敌人的战斗图准备的. 因为我方是没有战斗图的. 这个战斗类型参考 DQ1 的模式.

   4. Sprite_Picture
   显示图片的精灵类. 这里的图片, 包含我们使用事件 "显示图片" 里使用到的所有图片. 包括地图上显示的和战斗中显示的.

   5. Sprite_Timer
   显示计时器效果的类. 我们使用的显示计时器, 是由这个类来管理的.

Spriteset_XXX
   Spriteset , 可以理解成用于管理 Sprite_XXX 的管理类. 只有三个.

   1. Spriteset_Weather
   管理天气的类.  默认一共有三种雨、风、雪 .

   2. Spriteset_Map
   管理地图显示的类.  这个类是个关键的说. 这里具体说明下.
   1) 显示端口
   Spriteset_Map 内部生成了三个显示端口(Viewport), 分别是 viewport1, viewport2, viewport3.
      ☆ viewport1: 限定地图图块(默认z), 远景图(z = -100), 角色行走图, 以及飞行船的地面影子
      ☆ viewport2: 限定天气, 地图上显示的图片, 以及计时器的显示其 Z 值等于 50, 也就是里面的显示的内容总是比 viewport1 的显示内容靠前. 这就是为什么, 显示的图片总是可以遮挡住玩家, 但是无论你怎么修改图片的 Z 都是没有作用的.
      ☆ viewport3: 限定显示的亮度. 用于修改整体的亮度等问题.
   2) 地图图块
   所有的 VX 的地图图块显示都是这里定义的, 这个可以查看 create_tilemap 这个方法. 如果想修改图块的话, 可以从这里入手.

   3. Spriteset_Battle
   管理战斗画面的类. 这里也有三个 Viewport:
      ☆ viewport1: 限定战斗背景, 战场活动块(也就是背景那个黑色的椭圆部分), 敌人的战斗图, 我方角色的战斗图(这里默认的脚本没有调用, 仅仅给我们扩展使用的)
      ☆ viewport2: 限定天气, 战斗中显示的图片, 以及计时器的显示其 Z 值等于 50, 也就是里面的显示的内容总是比 viewport1 的显示内容靠前. 这就是为什么, 显示的图片总是可以遮挡住玩家, 但是无论你怎么修改图片的 Z 都是没有作用的.
      ☆ viewport3: 限定显示的亮度. 用于修改整体的亮度等问题.

剩下的剩下, 大家自己去看看吧.(其实是咱想偷懒)

zh99998 · 发表于 2011-3-20 20:32:40

o.o 完结了吗，来围观了~~

类变量的话，需要注意的一点是，不但在本类之内共享，连子类里都是共享的

class A
@@x = 1
def self.a
p @@x
end
end
class B < A
@@x = 2
end
A.a #=>2

复制代码

这个让咱纠结了好一阵子XD
于是发出来给各位提个醒

淘金鸭 · 发表于 2011-3-20 20:37:35

回复 zh99998 的帖子

然后呢？

淘金鸭于2011-3-20 20:41补充以下内容：
好吧107L也不是很诡异的现象

天使怪盗 · 发表于 2011-3-20 21:23:14

今囲観中で～す～由加铃酱コン~

爱丽丝·玛格特罗依德 · 发表于 2011-3-23 23:13:14

本帖最后由爱丽丝·玛格特罗依德于 2011-3-24 20:12 编辑

自定义脚本

   如果把 VX 原来自带的脚本称作默认脚本的话, 那么游戏制作者(不知道能不能叫做 RMer) 为了实现默认脚本没有实现的功能而写了一个自定义的脚本, 这个脚本个人命名为自定义脚本 or 外带脚本 .

基本设计原则
   由于 Ruby 本身就是 OO(面向对象, Object Oriented) 编程语言, 理所应当的由 Ruby 引申而来的 RGSS 与 RGSS2 也同样是面向对象的. 所以, 按照软件工程的设计理念来说, 基本的设计原则有以下几个需要注意:
   ★ 开关原则(The Open-Closed Principle, OCP)
   "模块应该对外延具有开放性, 对修改具有封闭性".
   也就是说, 设计者如果需要设计一个遵守 OCP原则的构件的话, 就需要采用一种无需对构件自身内部做修改就可以进行扩展的方法来说明构件.
   举个例子: Array 类有一个遍历的方法 each . each 在设计的时候, 没有使用具体的方法构件. 因为 each 所需要的功能是不可预见的. 我们可以使用 each 来显示, 也可以来增加数组内的数值.
   其实使用 Proc 来实现也有一点 OCP 的味道:

def show(num, proc)
proc.call(num)
end
show(1, Proc.new{|n| p "n = #{n}"})
show(1, Proc.new{|a| p "a = #{a + 2}"})

复制代码

这里没有修改 show 内部的代码(虽然很简单), 但是从参数上实现了外部的修改.

   ★ Liskov原则(Liskov Substitution Principle, LSP)
   "子类可以替换它们的基类".
   也就是说, 在重要功能的实现上, 子类需要按照基类的设计原则来实现.
   例如我们写一个场景类(Scene), 除了需要继承与 Scene_Base 这个基类以外, 我们还需要保证里面重要的三个方法, start, update, terminate 或多或少的需要实现. 而不是自己自定义一个 myStart 来替换 start 方法.

   ★ 接口分离原则(Interface Segregation Principle, ISP)
   "多个用户在用接口比一个通用接口要好".
   自定义脚本的在接口的设计上需要考虑到不同的使用者. 游戏制作使用者或者玩家. 两者提供的接口应该是一样的. 至少在脚本数据的操作权限什么的处理上是不一样的.
   例如默认的脚本提供了一个 Debug 的功能. 这个功能就是专门给制作者的(被破解后就另当别论了), 玩家有玩发布后版本的游戏是不能使用 F9 来调用 Debug 功能.

   ★ 共同封装原则(Common Closure Principle, CCP)
   "一同变更的类应该合在一起".
   类本身就是表示对现实生活中一类具有共同特征的事物的抽象. 比如人这个类. 你可以扩充一些方法到人这个类里去, 比如吃饭, 睡觉, 上6R. 但是不能将飞翔这个能力附加给人, 因为现实里人是不会飞的.
   就是说, Game 类集是用来处理游戏数据的, 但是最好不要在 Game 类集里添加 Sprite 类集的内容. 因为它本身在设计的时候是不处理这些的(当然有特殊原因的除外).

   ★ 发布复用等价原则(Release Reuse Equivalency Principle, REP)
   "复用粒度就是发布粒度".
   对于脚本使用者来说, 能看到一个号的脚本乃至系统持续性的更新是很高兴的. 但是他们又希望脚本作者在更新新版本的脚本的时候, 又不会对使用旧版本的他们产生影响. 也就是说, 旧版本的使用方法在新版本里是不会改变的.
   于是乎, 这个原则就要求脚本作者在更新新版本的脚本的时候, 能够兼容就版本. 让使用旧版本的使用者不改变使用方法二能直接使用新版本的脚本(相对于旧版本的功能).
   从软件工程的角度来说, 发布的时候, 脚本里的所有类, 模块等部分都是要求可以复用的, 也就是在后续的版本都会使用到.

   ★ 依赖倒置原则(Dependency Inversion Principle, DIP)
   "依赖于抽象, 而非具体实现".
   这个原则其实包换了两个含义:
      高层模块不应该依赖于低层模块，二者都应该依赖于抽象
      抽象不应该依赖于细节，细节应该依赖于抽象
   如果高层模块越依赖低层模块的话, 那么就意味着高层模块的复用性就越低. 这也是为什么 ASM(汇编) 编写的程序的代码可移植性很低. 因为它依赖于底层硬件设备.
   最好的解决方法就是在这两者之间添加一个中间抽象层. 这种做法的一个典型的例子就是微软的 DirectX. DirectX 中间就有一个硬件抽象层(HAL) 利用这个抽象层兼容硬件和软件模块. 这样, 如果硬件模块需要修改, 那么只要让修改后的硬件模块兼容 HAL 就可以了, 这样就可以完全不需要修改软件模块.

   ★ 共同复用原则(Common Reuse Principle, CRP)
   "不能一起复用的类不能被分到一起".
   这个其实很好理解. 实现某个功能的脚本不能将和这个功能无关的类, 构件封装到这个脚本里去. 因为这个无关的部分可能在其他地方被其他脚本所使用到. 如果这部分被修改的话, 那么就很容易出现问题.
   这个也可以理解成, 脚本冲突.
   产生的原因, 大部分是名字冲突. 包括:
   ◇ 变量名冲突 : 两脚本使用了一个很通常化的变量名字, RGSS2 理解成两个变量时一样的. 从而导致冲突.
   ◇ 方法名冲突 : 这个可以分成两类, 一个是方法名冲突: 两脚本修改或者使用了相同的方法名, 但是两个方法的功能是不一样的, 那么, 后定义的方法将覆盖掉之前的方法, 从而导致冲突. 另一个是使用 alias 定义方法别名的时候, 使用了相同的旧方法名, 这个就会出现很典型的堆载过深(SystemStackError) 错误.

帐号		自动登录	找回密码
密码			注册会员

[RMVX发布] 新手教程--从0开始学RGSS2(2013-09-21 修复索引地址)

评分

点评

点评

点评

评分

烫烫烫

贵宾