権兵衛 七篠 さんがあなたに Bitbucket でダイレクトメッセージを送信しました:
※Bitbucketで文面送ると空行が削除されるようで送信を何度かやり直しました、スミマセンorz
ご無沙汰しています、七篠権兵衛です。
文章の尺やその内容の都合上、本来のレスではなく、
こうして内密にメッセージをお送りする形になることをご容赦願います。
表題にあります追加案に関して、個人的にご質問とご意見を申し上げたく、一筆啓上するしだいです。
なお、文面がいささかぶしつけであり、感情的になっている面があることを
あらかじめお詫びとともに申し上げておきます。
なお本文は全力の七篠節で
ものすごーく長いのでメッセージの要約を付しておきます。
要約：
なぜ提案したし。
ご提案の拡張案について、拙作STARと酷似しており、正直かなり複雑な思いに駆られる今日この頃。
STARでは駄目なのか？
手前味噌ではあるが、(速度とユーザーインターフェースの問題こそあれ、)
拙作の機能は十分であると自負する。
これまでのユーザーが工夫や応用を通じて形にしてきたことを
無造作にエンジンへ取り込んでゆくことは、道義上の問題にとどまらず、
ＣＷの発展を支えてきたユーザーの自主性ならびに
今後のＣＷの将来性も阻害すると私は懸念する。
今後の開発の方向性
僭越承知で申し上げるならば、二つの方針があると愚考する。
(1)思い切ってSTARシステムの機能をまるごとエンジンに搭載する。
(2)地味だが小回りの利く拡張を重視し、飛び道具はユーザーに任せる。
(1)であっても、｢STARシステムの発想や手法をエンジンに搭載する｣目的なら
自分は協力したいし、折角だからパッケージの制約を越えた機能にしたいと思っている。
(2)が自分の本命。エンジン開発に参画する機会にの有無にかかわらず
STARのようなイノベーションを各自の手で形にする手がかりが提供されることこそが重要と考える。
本件拡張をなぜ実装しようと思ったのか。
そもそも拙作についてご存知だったか。
今後の方針はどのように考えているのか。
事情や背景を理解したよりよい提言、提案へ発展させたいと思うので
以上について、お答えいただけると幸甚である。
以下本文：
さて、｢メンバ選択分岐｣コンテントにおけるご提案の拡張(以下｢本件拡張｣と略記)について、
NEXTにおける評価メンバのデッドコピー元となった拙作、STARシステム(以下｢STAR｣と略記)と
個人的には、とても酷似するように感じるのですが
この本件拡張を提案なさられた経緯はどのようなものなのか
お伺いしてもよろしいでしょうか？
※STARは、プレイヤキャラクタ(以下｢PC｣と略記)の特徴を点数として換算し、
その合計点数が高いものを選択するロジックをパッケージイベントとして実装しており、
状態変数を使わずクーポンのみを用いた二進演算処理により、リソースとしての応用の便宜を図ったものです。
(現状では殆ど隠し機能扱いですが、｢人選の確実さ｣を判定するオプションも装備されています。
お求めはギルド、またはhttp://u3.getuploader.com/ghonbe/download/100/STAR%28std.%29.zipにて)
率直に申し上げれば、本件拡張の話にはいささか心中穏やかならざるものがあります、
あたかもNEXTの開発者のように自作を｢白須さん｣するような行為ではないか
もっとあけすけに云えば、｢k4nagatsuki さんまで拙作を剽窃盗用するのか？｣という疑念すら抱くのです。
また、個人的な心情の問題を抜きにしても、本件拡張の実装には慎重になるべきかと
愚考するところなのです。
・パッケージイベントで十分なのでは？
本件拡張に、私めが待ったをかける理由は、機能面からも説明可能です。
手前味噌かつ僭越承知で申し上げますと、処理速度と使いやすさ(と知名度)を除けば、
おそらく本件拡張の機能について、パッケージイベントを本質とする拙作STARで
その大半以上をカバーできるかと、私は愚考するのです。
本件拡張がデッドコピー元の評価メンバ(NEXT1.50エンジン)に範を取るのだとするならば、
評価の対象はまずクーポンからになるかと存じますが、
拙作は仕様上コンテントツリーの形で実装できるあらゆる判定を得点に換算でき、
それら判定はANDするなりORするなりNOTかけるなり、
コンテントツリーの許す限りに組み合わせ出来る様になっています。
またクーポンの条件だけでも、｢｢本人以外｣の所持するクーポン｣を評価条件にした事例がございます。
(他のメンバが役割クーポン等を所持しているかどうかのチェックなどに利用可能)
何より、パッケージイベントという実装は、エンジンのレベルで実装された機能が持つ、
今後の｢仕様衝突｣という懸念と本質的に無縁であります。
・もちろんパッケージは万能ではないにせよ
開発者として、私はSTARのほうが本件拡張に優るはずだと、自負していますが、
純粋にその機能を比較した場合、処理速度と使いやすさの二点では
パッケージイベントよりエンジン組み込みの類似機能が優る可能性も承知しています。
コールをできる限り廃してリンク中心にするなど工夫はしていますが。
パッケージイベントであるため速度において劣る面があるのは事実です。
(Pyの処理速度が、1.20に比すれば長足の進歩であることはいうまでもありませんが)
またパッケージイベントであるため、評価パターンをカスタムする場合
エディタでのコンテントツリー構築に習熟する必要があります。
移植の容易に配慮し状態変数を廃したことから、二進クーポンの扱いが必要になる面もあります。
さまざまな制御クーポンを持ち、また多量の解説文章を付して、
シナリオへの導入はパッケージのコピペで完結させる設計とするなど
扱いやすさには可能な限り留意するところですが、
エディタに専用のユーザーインタフェースを持たないぶん、
STARは本質的に扱いの難しさを抱えているという側面は否定しがたいところです。
・既存機能をエンジンで真似る問題
NEXTのまねをするべきではないという理由、すなわち、
ユーザーの応用と工夫で実現した機能と類似した機能を、
専用エディタ抱き合わせでエンジン搭載することに私が懸念を持つのは、
それがＣＷのこれまでの進歩を支えてきたユーザーから
自主性や将来性を奪いかねないと懸念しているからでもあります。
専用エディタ抱き合わせで、扱いやすくわかりやすい形で丸めこまれた｢新機能｣が
エンジンに追加されれば、なるほど利便性は向上しますし、
ユーザーはあたかもCWの自由度が増し可能性が拡張されたように錯覚するかもしれません。
しかしそれは応用と工夫で獲得した自由や可能性ではなく、ただ単に与えられた自由であり可能性です。
なにより今後その自由や可能性を誰が担保するのかといえば、
それはエンジンのユーザーではなく開発者だけなのです。
そうした｢すでにある機能の再導入｣はあしざまに言えば｢私物化｣というものであり、
たとえCWpyがオープンソースであるといえど、現状においてすべての機能は｢作ったもの勝ち｣ですから、
はじめに実装したものの独裁状態であることは変わりありません。
策定に参加しなかった今後のＣＷユーザーたちからすれば、
初めに作った人間が策定した仕様を問答無用で強いられることになるわけです。
ユーザーも扱いやすさを得てそれで満足するならば、
ユーザー自身の応用や工夫はこの扱いやすい｢新機能｣の枠内に
囲い込まれてしまうようにも思うのです。一見、自由や可能性を手に入れたように見えて、
実際はＣＷのこれまでの発展を支えてきた自主性や将来性を開発者に手放しているわけです。
｢既存機能をエンジンで真似る｣ということはそうした事例を増やす側面があるという意味でも
やはり慎重な検討が必要であるように、私は思うのです。
(本来こうした機能策定にはCardWirthの仕様やゲームデザイン自体を検討する場が必要だと愚考しますが、
かんじんの愛護はそれをする気力に乏しいという大問題があります。)
(すくなくともNEXTの類似機能について独断と偏見を述べるならば、
応用と工夫で獲得した他人(七篠)の成果を、開発者が何の断りもなく
言葉巧みに横取りしているだけだと断言できます。
成果を奪われた側としては、ＣＷコミュニティへの信用を失い、二度と横取りされぬよう尽くすこととなり、
自主性や将来性はおろかその先の自由や可能性をも望めなくなるのです。)
・あと変な話というか、面倒くさい話(?)として
まったくの蛇足なのですが、NEXTの機能のデッドコピーを新たに行う行為は
｢#162: Nextシナリオ対応について｣にて沸いてきた所謂｢NEXT信者｣あたりを
刺激しかねないという意味でも慎重に検討する必要があるようにも思います。
・今後の開発の方向性について。
個人的には疑問や懸念のある本件拡張ですが、
この開発、あるいはPyの方向性として、今後二つの方向性が考えられると愚考します。
(1)STAR同等かそれ以上の機能を詰め込んだ｢本件拡張｣の開発
(2)｢本件拡張｣でなく、パッケージの機能じたいを強化し使いやすさと速度を補う開発
・今後の開発の方向性(1)どうせやるなら、徹底的に。
どうしても本件拡張を開発したいのであれば(1)になるでしょうか。
開発を通じて、｢STARシステムの発想や手法をエンジンに搭載する｣
ことができるのであれば、私にとって本件拡張の開発はやぶさかではありません。
むしろ積極的に参画すべきだとも思っています
パッケージの制約で出来なかったことをぜひ実現してみたいと思うところです。
エンジン組み込みで速度を向上させ、エディタに専用インタフェースを設けて
様々な判定の自在な組み合わせを可能とし、その結果も柔軟に出力できるようにする
(足きり点を0ではなく可変にする、あるいは多段分岐や変数対応するなど)
といったさまざまな拡張を提案したいとも思っています。
ただ、個人的には、(2)の方針、すなわち
ユーザー自身の応用や工夫に任せてみるのはどうか、とも思案するところです。
これはあくまでいちＣＷユーザーの私見ですが、
私たちはNEXTの複製ではない、｢Lynaのやり口を追従しない｣エンジンをこそ
世に問うべきではないかと思うのです。
・今後の開発の方向性(2)Of the user,by the user,for the user!
私は、ＣＷにおける自由度や可能性は、エンジンを作ることのできる
誰かの裁量で与えられたり、与えられなかったりするものではなく、
むしろユーザー自身の応用と工夫こそがもたらすものだと、信じています。
自主的に、工夫や応用を尽くしてきた、先人の成果や精神を、
エンジンの機能という形で横取りしておいて｢新機能｣などと喧伝するのではなく、
彼ら彼女らの努力や取り組みをできうる限りに将来へと生かすべきなのです。
本当に必要なものはなんであるか、エンジンがユーザーに提供すべきはなんであるか、
それは自主性や将来性だと、私は確信します。
すなわち、
ユーザーの、自主性や将来性を担保した、
ユーザーによる、応用と工夫を引き出すエンジンこそが
ユーザーのための、そしてカードワースの未来のためのエンジンになると思うのです。
華々しい新機能より、地味でいいから小回りの利く拡張を重視して
飛び道具はユーザーに任せたほうがいいのではと、私は考えるのです。
(1)の方針、｢STARシステムの発想や手法をエンジンに搭載する｣であっても
私は出来うる限りに協力したいと考えるのですが、
その一方で、こうした参画、協業の恩恵を、できることなら自作以外、つまりSTAR以外にも
広げたいと思うのです。私と同じくＣＷで工夫や応用を重ねてきた人々、
あるいは自分のようには参画の機会に恵まれないかもしれない、
はるか先のＣＷユーザーの方々にも、STARのようなイノベーションを形にする手がかりを
広く提供したいと、私は願うのです。
・拡張の具体例
地味だが小回りの利く拡張、というものは、たとえばそれは、
状態変数をパッケージ自身に保持させたり
(パッケージをライブラリとして運用できるような想定だが、
将来的には変数といわず札や素材データなどもパッケージ格納ないし
エディタレベルで紐付け(移動やコピーの際に連動して複製)できるようにするか？
アクセスする際は｢\\[パッケージ名]\パッケージ内部変数｣みたく、
円マーク二重&角括弧のような特殊表記でパッケージ名指定とか。)、
あるいは、体力その他CWのパラメタを状態変数としてアクセス可能にするとか
(ex1:$\\(選択メンバ)\体力$
(円マーク二重でシステム状態変数とか。別途上限を自由設定する変数が必要か？
各変数の最大値に対する比率換算で代入/分岐する拡張もあると便利か。)
ex2:%\\(メンバ＿６)\名前%
(存在すればtrueで名前表示、不在ならfalseで表示なし？
存在しないメンバの場合常に0または最大値をを返答するか？))、
はたまたエディタ側の大掛かりな対応になりますが、マクロ機能を搭載して
簡易な設定で複雑なロジックを出力可能にするなど
(ロジックごとにプラグイン形式にすればロジックの更新はプラグイン差し替えで可能。
エディタにプラグインの開発環境が付録すれば多分無敵か？)、
いくつか自分なりに考えてみた例ですが、
用途や応用はユーザー自身の工夫次第というふうに
｢何ができるかはユーザー任せ｣にできる拡張を実装する方がほうが
個人的には望ましい、あるいは使う立場として楽しいと愚考する次第です。
・そもそも、どうしてそうした本件拡張は提案に至ったのか？
ここまでに申し上げた通り、私こじんとしては、
可能ならば本件拡張の実装をご再考いただきたいと思うところです。
しかしながら、なぜそうした提案が行われたのかについても
私は知りたいと考えています。
現状の、この文面は、あくまで私めの思うところの表明に過ぎず、
先方が提案を行うにいたった事情を承知しての発言ではありません。
そもそもご存知なかったのかとも愚考しておりましたが
あるいは拙作をご承知のうえで、それでも必要と判断する事情があったのかとも考えられますし、
はたまた他の方からご提起なられた提案であるのか、
そうした、本件拡張に関する事情を、私は把握したいと思っているのです。
私は、もし可能ならば、このメッセージを私めの一方的な主張とせず、
CWの将来へ何をどう搭載するべきかの、建設的なやりとりにしてゆきたいと願うところです。
・結句(という名の蛇足めいたなにごとか)
ちなみに、拙作と類似する機能の実装に関して、
参考にしたのか否かという問い合わせをしたところ、
例のエンジン開発者は、このように発言しました。
｢僕の作ってるソフトの一機能に対して、
「項目に重みを付けて評価する方法は自分
が発明した物だこのパクリ野郎」と主張す
る怪文書が（また）来たんだけど、この人
古代ギリシャの数学者か何かなのかな…。
今の時代では初心者用のアルゴリズム本と
かに載ってるレベルですよ…。｣
できることならば、やはり先方におかれましては、
(あるいは私たちは、)このような開発者とは
違うエンジンを目指すべきではないかと希望しまして、
筆をおかせていただくしだいです。
長文乱筆失礼しました。