设为首页收藏本站|繁體中文

Project1

 找回密码
 注册会员
搜索
查看: 2055|回复: 6
打印 上一主题 下一主题

[交流讨论] 不是很懂为啥RM的脚本架构要这样设计

[复制链接]

Lv3.寻梦者

梦石
0
星屑
1934
在线时间
403 小时
注册时间
2015-8-30
帖子
395
跳转到指定楼层
1
发表于 2018-8-31 20:26:51 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

加入我们,或者,欢迎回来。

您需要 登录 才可以下载或查看,没有帐号?注册会员

x
既然把$scene这玩意扔了,为啥还留着$data_***和$game_***
我觉得架构应该这样设计:
把DataManager模块扔了
然后咱做个Data模块,除了用来实现原来DataManager的功能,单例类里面还有attr_accessor
比如Data.actors,Data.items之类的
接着把Game_***什么的类都扔了,造一个Game的Namespace
Game模块里面有Game::Map,Game::Party之类的东西
$game_map.map_id这种画风全部变成Game::Map.map_id
至于load_database里面$game_*** = Game_***.new的画风都变成Game::***.init
RUBY 代码复制
  1. module Data
  2.   class << self
  3.     attr_accessor :actors
  4.     attr_accessor :classes
  5.     attr_accessor :skills
  6.     # ...
  7.   end
  8.   module_function
  9.   def load_normal_database
  10.     self.actors = load_data("Data/Actors.rvdata2")
  11.     # ...
  12.   end
  13.   def create_game_objects
  14.     Game::Temp.init
  15.     Game::System.init
  16.     # ...
  17.   end
  18.   # ...
  19. end
就像这样

评分

参与人数 1+1 收起 理由
张咚咚 + 1 官方:能全局变量搞定的事儿为啥要用模块= .

查看全部评分

小仙女一枚~

Lv3.寻梦者

梦石
0
星屑
4583
在线时间
1205 小时
注册时间
2016-4-7
帖子
982

开拓者

2
发表于 2018-9-1 08:31:15 | 只看该作者
需要注意的是 gamexxx并不都是单例类 datamanager十分必要
改出一堆namespace一堆单例类 有点oo过度的感觉
就架构上来说va是最合理的 反而到了mv一方面因为js的原因再加上我觉得写mv的水平明显逊色于写va的 折腾了一堆没必要的xxxmanager

点评

可以写一个含有save和extract功能的Game::Savable模块,让需要存档的东西include(Game::Savable),再重写一些方法来实现  发表于 2018-9-1 14:32
仔细想想这些类在读档的时候存在着两个实例(当前本身就有的和反序列化的时候创建的)  发表于 2018-9-1 14:11
Game下面不是单例类的可以new,DataManager的功能Data也能实现,而且Ruby不就是完全OO的语言嘛  发表于 2018-9-1 10:37
附庸的附庸不是我的附庸,女儿的女儿还是我的女儿。CK2沉迷ing
回复 支持 反对

使用道具 举报

Lv5.捕梦者 (版主)

梦石
28
星屑
10170
在线时间
4673 小时
注册时间
2011-8-22
帖子
1279

开拓者

3
发表于 2018-9-1 08:33:34 | 只看该作者
我觉得主要原因是序列化的时候灵活直观。

至于用全局变量还是静态类,既然两者等价那就无所谓合理不合理,并不是全局变量就低人一等。

点评

虽说是等价的,但是全局变量太灵活,封装成模块比较安全  发表于 2018-9-1 10:37
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 注册会员

本版积分规则

拿上你的纸笔,建造一个属于你的梦想世界,加入吧。
 注册会员
找回密码

站长信箱:[email protected]|手机版|小黑屋|无图版|Project1游戏制作

GMT+8, 2024-6-9 18:53

Powered by Discuz! X3.1

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表