GBAT2STextのサポート廃止

[snext1220]

今すぐという話ではありません。

ただ、Playgroundの強化を進め、フロチャ機能＋入力補助機能が強化され、GBATを採用する利点が弱まってきているように感じています（タグを意識しなければならないというのはありますが、タグ挿入機能のUpdateでかなり負担は軽減されるのではないかと）。

今後、メンテナンスの負担を絞るという意味でも（これまでもGBATが鬼っ子になることが多かったため）、GBAT2STextを廃止し、Playgroundを唯一の開発ツールとして絞っていけないかと考えています。

繰り返しですが、今すぐという話ではありませんし、大きな方針転換なので、現在ご利用いただいている方の感触を伺いつつ、決めていければと。ご意見いただけますと幸いです。

※GBATの機能で、現在のPlaygroundで足りないものなども挙げて戴ければ、Playgroundブラッシュアップのきっかけにもなるので歓迎です。

[RYU-DS]

SGMLとGBATに機能的な差が無くなったとしても、インターフェースとしてのとっつきやすさにはDOSとwindowsくらいの差があると思います。
少なくとも自分は、ここまでGBATで作成のノウハウを得た現在であれば移行は出来ますが、最初に始める時にいくら多機能でもSGMLしかなかったら、始めていなかったと思います。
対応の負担がかなり重いであろう事は素人的にも想像に難くないですが、大幅に参加の間口を狭める事になるという事を理解した上で、それでもという事であれば仕方が無いとは思いますが…
今現在、玄人的な方しか参加していないという事実を受けてである事も理解していますが、やはり自分のような素人が参加する可能性が減ってしまう、というのは残念に思います。

[snext1220]

前投稿の繰り返しになりますが、直近でGBAT2STextを廃止していくことはありませんので、その点はご安心ください。

ただ、まさに仰るように、ツール類並行メンテの負担は重く、整理／統合の検討は必要と考えていまして。その可能性の一つが、将来的なGBAT2STextの廃止であり、そのためにPlaygroundにどのような機能が必要か、を議論するのが、このIssueの目的とお考え戴ければ。
＃GBAT2STextの廃止がありきではないとは思っております。

現在の反応を伺う限り、#87 で提示しているSGML前提の新機能案では不足で、タグ構造を完全に隠蔽するという意味で、以下のような機能まで作り込みが必要なのかなと感じています。

• フロチャからのシーンの追加／更新／削除
• enemy、item、flagなどの入力フォーム
• 各シーンの入力フォーム

正直、ほぼ現時点で想定されるフルセットなので、ここまでやるなら、結局GBAT2STextを維持した方が良いか、という話もあります^^;

[RYU-DS]

結局、「GBATの廃止にはSGMLのGBAT（レベルのインターフェースの軟化）化が必要」となると負担は同じという事ですね…
「GBAT対応というインターフェース軟化の負担」が、最近猛烈に進んでいる「多機能化」によって累進的に重くなっている事は感じていましたが、もうすでに遊び（無償）でやるレベルを超えているのもあり、そこらへん全体を見たバランス（力の入れ所）を考える必要があるかもしれませんね…

[snext1220]

結局、「GBATの廃止にはSGMLのGBAT（レベルのインターフェースの軟化）化が必要」となると負担は同じという事ですね…

当面を見ると、ではありますが、仰る通りかと^^;
ただ、長期的には、外部ソフトウェアへの依存は制約の割にコストも高いので、Playground統合はそれなりに意味があるとも。

そこらへん全体を見たバランス（力の入れ所）を考える必要があるかもしれませんね…

オープンソース開発の宿命ですね～^^;
まあ、遊びとは云いつつ、折角ゲストの方々も集まり始めた＆個人的にはもちっと先?を見据えたいという思いもあり、あまり先は考えずに、開発を進めていこうかなとは。

もちろん、なにもかもは不可能なので、
ここからはサポートレベルを緩めていくところからかな、とは思っています。

サポートレベル、というと、大仰ですが、要は、これまではSGMLとGBAT、マニュアルは完全一致を目指してきましたが、ある程度ずれてても許してね、という意味で。もちろん、基本は一致させていく努力はしますが、重点的に開発を進めていく箇所をまずは優先しますよ、というニュアンスです。

当面何が変わるわけではありませんので、是非今後ともよろしくお願いいたします～

[snext1220]

本件、New Playgroundのリリースで、一定の役割は終えたと思える（思いたい）ものの、GBATに慣れてきた皆さまもいることから、当面はサポートを継続する方向で参りたいと思います（ただし、上の通り、対応優先は若干落ちるかも）。

今後、New Playgroundが安定してきたところで、本IssueはReopenするかもしれません。

[toki-sor1]

私もテキストエディタ、GBATと両方の環境でシナリオを作り、Playgroundで動作確認を行ってきましたが、どの方法（システム）もそれぞれに良さがあり、欠点もあるという感じでしたよね。

様々な方法でシナリオが作成できるところもSTextの魅力です。
ただ、システム開発やサポートを全ての方法に合わせようとすると、その分サポートも開発（メンテ）も負担が増えるのは勿論のこと、 「Aの方法ではできることが、Bの方法ではできない」 など、 シナリオを作る側・開発側ともに混乱の元になってしまう かなと思います。

GBATがSTxetにご参加いただける切っ掛けとなった執筆者様のお話を拝見し、可能であればこのままサポートを続けられたら……という想いもありますが、 STextは多くの方々が簡単にシナリオを作成できる環境作りを目指して日々進化・改善しているシステム なので、やはり、 徐々にでも 「システムをより良くできる環境」にシフトしてゆく必要があるもの だとも考えています。

難しく悩ましい問題ではありますが、私個人は、 「GBAT2STextのサポートは暫く続けつつ、何処かのタイミングで廃止し、Playgroundを唯一の開発ツールとする」というご提案に賛成 です。

システム開発の過程で寄せられたご意見やご提案によってSTextは日々成長しているので、今後も様々な方法の良いところを取り入れて、 多くの方が手軽に気軽に、そして楽しくシナリオを作成できる環境 を作っていきたいですね！

[snext1220]

ご意見ありがとうございました！

シナリオを作る側・開発側ともに混乱の元になってしまう かなと思います。

まさに、これですよね；；
条件分岐の新構文なども随分と混乱してしまいましたが、さりとて、個別の環境ごとに相違点を解説するかというと、悩ましく；（今後はNew Playgroundが加わったことで、悩みが深まりました^^;）
そもそも最初のとっかかりで、「これ使って！」と一言で言えないのは辛いですものね。。

「GBAT2STextのサポートは暫く続けつつ、何処かのタイミングで廃止し、Playgroundを唯一の開発ツールとする」というご提案に賛成 です。

ご賛同ありがとうございます！

何処かのタイミング＞ひとつのタイミングはミドル70（未定ですが）で、実際に開発された皆さんのご意見を伺ったところで、もうひとつのタイミングは、現在GBATを利用されているRYUさん、ちゃなさんのお二人に実際に利用戴いたタイミング、かなと思っております（ちゃなさんの方は、どこかでNew Playgroundで新作も作成されたい、と呟かれてました）。

多くの方が手軽に気軽に、そして楽しくシナリオを作成できる環境 を作っていきたいですね！

はい、是非よろしくお願いします！
特にNew Playgroundは、GBATを十分に吸収して、使い出良いツールに育てていければと思っていますので、是非にご協力のほどお願いいたしますm(_ _)m

[cocotori]

複数のツールをサポートしていくのは
現実的に非常に困難だと思いますので、
[いずれ]GBATサポートを廃止する方向性に賛成です。

new playgroundが相当にいいツールになってきましたので、
なんとかこっちに統一する方向にしていけたらと思います！

[snext1220]

new playgroundが相当にいいツールになってきましたので、
なんとかこっちに統一する方向にしていけたらと思います！

そう仰って戴けると、NewPgを開発した甲斐があります…！

いずれ廃止＞はい、無理ない範囲でその方向にカジ取りしていきたいですね。
おそらく、非推奨機能については、（いきなり削除するのではなく）以下のような段取りで徐々にフェードアウトする形になるかと思います。

• 新機能を反映させない（互換性維持を除く）
• 軽微なバグフィックスを停止
• 互換性維持のためのメンテを停止

ということで、どんなに短くても1年以上はサポート継続になると思うので、心配なさらないでください＞現在利用されている方