【RGSS3 入门教程大家写 第二弹】活动开始！

taroxd

IamI 发表于 2014-6-22 01:54
OOP 概念是正常成长过程中要转过的最大一个弯。
函数范式是习惯了OOP之后要转过的第二个大弯。
君不见多 ...

防止你们说我装逼，我先把下面的题目也去掉得了。

我的标题是 “OOP概念” 而不是 “OOP思想”，你觉得很装逼么？ 可否给我想一个不装逼的标题？为了更好的概括，本帖下面所有的OOP均指这个意思。
我想不出什么标题可以更好地概括“类、对象、方法”这些东西了。
很多人只求一个能用的界面，可是当你不知道Scene和Window是什么的时候，你怎么写出能用的界面？
正是因为OOP这个弯很难转，在RGSS中又不得不转，我才会在这里重点提及。
不求OOP登堂入室，只求能懂什么是类，什么是实例，什么是实例变量，什么是方法。

至于块和迭代器，我也不觉得是什么很装逼的东西。
标题有迭代器，但我不会提到怎么制作自己的迭代器。
但 block 这种东西，还是知道一下比较好吧。只算 each 这个单词的出现次数，RGSS3的默认脚本中已经有近百次了。
为了再简化一点，防止引起误解，我把标题中的“迭代器”删掉得了。我本来指的迭代器，是指 Ruby 中 each 这类的方法！


“不会弄得很深”你加上了红字，我不懂这是为什么。可能是我的语文水平不好吧。比如迭代器，不求编写只求使用。OOP部分不需要登堂入室，但是至少之后要可以理解RGSS的框架吧？当然，

我的想法是：分支循环这种东西，上一次有写，也没什么理解的难度。而OOP和block是理解起来不容易，却恰恰是在写脚本的时候十分常用的东西

我自认为我编程水平不高，因此才会想要弄这样一个活动。否则我要装逼，我为什么不自己写教程？

到时候希望你能来看看，看看我的问题，再看看我是不是在装逼。如果愿意的话，再来写点什么东西吧

3106345123

我觉得将va帮助手册汉化完全 比一群人发教程要好 毕竟帮助是va本人写的而且较客观 教程是一群人发的所以会掺杂着各种各样的个人理解

taroxd

3106345123 发表于 2014-6-22 07:54
我觉得将va帮助手册汉化完全 比一群人发教程要好 毕竟帮助是va本人写的而且较客观 教程是一群人发的所以会 ...

脚本部分已经有完整汉化。我去技术区发个帖转载一下吧

taroxd

3106345123 发表于 2014-6-22 07:54
我觉得将va帮助手册汉化完全 比一群人发教程要好 毕竟帮助是va本人写的而且较客观 教程是一群人发的所以会 ...

事件的话，把鼠标悬停在事件框上，那些说明已经够用了。

VA图书馆里，S叔的教程也十分优秀

克莉丝

这个时候把雪姐姐挖出来不就行了

DeathKing

无论是OOP还是FP，都是对于解决某一问题的思维建模。思维角度不一样，看问题的方面也不一样，自然解决问题的办法也不一样。

二者殊途同归，都是用于解决问题。OOP重在黑盒抽象，FP也有这个用途，不过更在乎“高阶语义”。像什么map、inject都是Ruby从FP那边抄来的（在SICP中，要求读者实现map、for-each、filter、reduce这几个高阶过程，实际上其它几个过程都可以通过reduce来实现。Ruby中的map、select、filter、inject、each也都是类似的可以由reduce来实现），它们都只是高阶语义而已，并不是什么很本质的东西。

Block正是Ruby从Lisp那里面抄坏的东西，Lisp中函数是一等公民，直接可以当做变量去传递。Ruby不行（Ruby里面Block、Proc、lambda还有方法对象等等，概念很混乱），需要用一些魔法，比如传递代表方法的符号（比如你上面的:*)等等。这是因为Matz想让Block“看起来像控制结构”，结果反而让问题变得更糟。

下面就给出了一个对表做map操作的实现，它用到的全是基本过程，而且你会发现它就是课普普通通的递归函数而已（没有写成尾递归调用或者CPS）

SCHEME 代码复制

(define (map proc lst)
  (if (null? lst)
    '()
    (cons (proc (car lst)) (map proc (cdr lst))))))

(define (map proc lst)


  (if (null? lst)


    '()


    (cons (proc (car lst)) (map proc (cdr lst))))))

结论就是，像迭代器这种东西，不用讲得太细，让大家知道是这么回事，并且会使用就行了。迭代器本身的实现非常复杂而精细，仔细考察的话都足够写几篇Paper了。

taroxd

DeathKing 发表于 2014-6-22 09:07
无论是OOP还是FP，都是对于解决某一问题的思维建模。思维角度不一样，看问题的方面也不一样，自然解决问题 ...

结论就是，像迭代器这种东西，不用讲得太细，让大家知道是这么回事，并且会使用就行了。迭代器本身的实现非常复杂而精细，自习考察的话都足够写几篇Paper了。

本来就是这个打算啊喂 都是你们这群大触带坏的！！害得我11L还用了红字！

还有一个很重要的问题……URG3不能坑啊……

IamI

不需要。
写一个Scene一个Window，只要知道class、Start、Terminate是一个固定格式，$data_*，$game_* 是什么含义就可以了，这本身就是OOP黑箱的意义。
我真的不用 Block，除非只有一行。在生产环境写 reduce:* 的话 Review 的时候一定会被人爆扁一顿。
这是我的观点：使用 for，语义清晰可辩。对初学者去讲each，map，collect这种本来就是发明用来装逼高深的方法没有意义。
迭代器很多时候特指使用yield的自定义迭代器。

简单而言：如果这是一篇RGSS的语法说明，几千字可以他很快解决问题。
如果是一篇新手向的教程——你必须先考虑对方有多蠢，没错是那些十几岁就想着要做一个网游的家伙们有多蠢，如果不考虑请参见上一条。毕竟了解什么是OOP无助于他立即写出什么看起来很厉害的玩意或者某腾讯游戏升上一级。

taroxd

IamI 发表于 2014-6-22 10:01
不需要。
写一个Scene一个Window，只要知道class、Start、Terminate是一个固定格式，$data_*，$game_* 是什 ...

感谢你的认真回复。

写一个Scene一个Window，只要知道class、Start、Terminate是一个固定格式，$data_*，$game_* 是什么含义就可以了，这本身就是OOP黑箱的意义。

原来你是这么看待RGSS的……好吧你赢了。这样确实没有什么问题。
但我坚信，对OOP一定程度的理解是有好处的。

我真的不用 Block，除非只有一行。在生产环境写 reduce:* 的话 Review 的时候一定会被人爆扁一顿。
这是我的观点：使用 for，语义清晰可辩。对初学者去讲each，map，collect这种本来就是发明用来装逼高深的方法没有意义。

RGSS3默认脚本装逼我有什么办法……Ruby就是这样一个装逼的语言。
但是就我个人而言，我认为 each、map、inject、select 这种方法，无论是写起来还是理解起来都比 for 来的容易

迭代器很多时候特指使用yield的自定义迭代器。

是的。你也可以看到，yield这个词除了Fiber.yield之外，在RGSS3默认脚本中也有所应用。
Game_Pictures 和 Game_Followers 都定义了 each 方法，在 Game_Interpreter 中也有自定义迭代器。

简单而言：如果这是一篇RGSS的语法说明，几千字可以他很快解决问题。
如果是一篇新手向的教程——你必须先考虑对方有多蠢，没错是那些十几岁就想着要做一个网游的家伙们有多蠢，如果不考虑请参见上一条。毕竟了解什么是OOP无助于他立即写出什么看起来很厉害的玩意或者某腾讯游戏升上一级。

我没有说这是新手向的教程。我已经很明确，这个教程是面向学习过“第一届RGSS3入门教程大家写”，或者对脚本有初步了解的人。

DeathKing

IamI 发表于 2014-6-22 10:01
不需要。
写一个Scene一个Window，只要知道class、Start、Terminate是一个固定格式，$data_*，$game_* 是什 ...

我反而觉得在Ruby里面使用for反而应该被暴扁啊！而且for还是each等迭代方法的语法糖……像for这种东西，还在外层环境引入了一个新的变量，用迭代器的话，直接就在闭包里，安全无毒。

reduce、map、select之类的语义明显比for强啊！

Ruby Style Guide： https://github.com/bbatsov/ruby-style-guide

Never use for, unless you know exactly why. Most of the time iterators should be used instead. for is implemented in terms of each (so you're adding a level of indirection), but with a twist - for doesn't introduce a new scope (unlike each) and variables defined in its block will be visible outside it.

反正都不是什么很本质上的东西，工程上的实践啦~