以前からの検討は結局のところ、『どんな相手でも同じ条件で勝てる』というものです。
これ自体はまあコンセプトなので悪くはないのですが。
『これが呪い？』『普通の魔術と何が違うの？』と聞かれると疑問ではありまして。

考えた結果友瀬的に、『呪い』につきまとう『穴二つ』的リスクがないのが、気になっているみたいです。

ということで、そういう観点での、妄想的なネタ。

ネタ１：呪いの強化と反動。†

例えばこんな感じ。

• 行動『血の呪い』。行動番号４。
• 上記行動に成功すると、『自身の呪い力』アップ。
  • この状態で相手に呪いを与えると、普通より＋２多く呪いがつく。
  • ただしこの状態では、こちらは『毎ターン１ダメージを受ける』。

相手への呪いの影響力を大きくするかわりに、自分へも負荷を与える。
だんだん呪いが負荷になり自滅する、呪いっぽい代償行為。

効果・反動のバランス調整は必要。
例えば、反動を『毎ターン自分に呪い１点』とした案がある。
でもこの場合『相手から呪いを受ける』ことがないと『9ターンデメリットなし』と変わらないので、反動としては弱い。
ダメージなら『相手の攻撃によりもろくなる』意味で、デメリットとして厳しくなる。

でも例えば反動が『毎ターン呪い２ or ダメージ２』となると、ちょっと厳しすぎになりそう：
相手に『逃げ回る』メリットが出てくるため。

ネタ２：『反撃型』の呪い。†

例えば、こんな感じ。

• 行動『恨みの刃』。行動番号26。
• これを相手の攻撃にあわせると、相応の『直撃＆反動』ページへ。
  • こちらは、それなりに痛いダメージを食らう。
  • その代わり受けたダメージ量に応じて、相手にもそれなりに大きな呪い反撃 and/or こちらの呪い能力強化も発生。
• 実施して、しかし相手が攻撃していないと、こちらは反動だけを受ける（例えば自分に呪い・ダメージ）。

一種の『当身反撃技』。
ダメージで返すのではなく、呪いで返すのが特徴。

通常の当身反撃が『成功するとこちらは無傷、失敗してもバランス崩すくらい』なのに対して。
こちらは呪いっぽく、『成功してもこちらはダメージ、失敗しても反動あり』。
かなり不利な分、効果は強くしてもいいかな、とか思ってます。

ネタ３：ルールによる呪い†

それ単体ではほぼ意味がない行為だが、それをつなげることで術となる、という攻撃。
LW的ではないですが、例えば『南に墨の塊、北に鏡、東に鶏の死骸、西に卵』と並べると、その中心にあるものが呪われる、みたいな。

『呪いの反動は？』と思われるかもしれませんが。
この場合の反動は、『数手番の行動が完了するまでなにも効果がない』という点です。

一応、以前に幻術師で似たようなことをやったことはあります：
専用呪文を６回成功させると、驚異的な自己ブーストが発生する、という感じでした。

上記キャラでは『得点ページを開かなくても、この専用呪文は使える』というような条件緩和はありましたが、それでも相応に手間です。
つーか、普通『呪文を６回成功』できたら、それだけで勝利できますよね。

とりあえずはそんな感じにて。

ご意見などがあれば。

基本的な原因は、かんたんです。
Twitter側のアクセス制御が走っており、タイムアウト待ちしている。

もう少し具体的にいうと。
このプラグインは内部的に『Twitter側から提供されている HTMLソースコード』をそのまま出力するのですが。
その中で「Twitterサーバ上にあるJavaScriptファイル」を読み込むように記載されています。
で、そのJavaScriptのダウンロードが、制限されることがあるのです。

「Twitter側がなぜ制限しているのか」はあちらの都合なのでよくわかりませんが。
TwitterのAPIは「15分にｘ回」と制限されていることが多いため、それ類似かな、と思っています。
この場合、JavaScriptをロードするのは個々のクライアント側（ブラウザ側）。
例えばブラウザのリロードや、pukiwikiゆえの「編集やプレビュー」の繰り返しがとかが原因かな。

ともあれ、上記の通り遅くなる原因がわかっているのですが、あんまりおいしい回避策がないんですね。

一応の回避策としては、上記で問題となっている JavaScriptファイルのキャッシュ処理かな。

• TwitterのJavaScriptを、プラグインが「pukiwikiサーバ側」にダウンロード・キャッシュする。
• プラグインが生成するHTMLのうち、上記JSを呼び出している部分を TwitterサーバではなくPukiwikiサーバにする。
• いつまでも古いキャッシュでというのも問題なので、例えば1日以上古かったらリロード、とかする。

Twitter側が（おそらく輻輳を嫌って）何度もリロードするのを嫌がっているので。
その部分を pukiwikiサーバ側で受け持つ、という話。
もちろんその分pukiwikiサーバ側に負荷が増えるので、無条件にはできないかな。

ちなみに友瀬の pukiwikiサーバでは、実験的にJavaScriptファイルを手動でダウンロード＆サーバ側においています。
それで、うまく動いていますよね？

ご意見などがあれば。

友瀬も昔、ROのホムンクルスAI関連でちょっと書いたことがある。
要点は『必要なのは下記３つの能力』という話。

1. どんなことをやりたいのかの手順を「日本語で」書ける（分析能力）
2. 手順の中の重要点を明確にし、「論理的な流れ」に書き直すことができる（アルゴリズム作成能力）
3. 「論理的な流れになった日本語」を元に、プログラム言語への「翻訳」ができる（プログラム能力）

開発初心者に教えるべき・学ばせるべきは、1つ目・2つ目だと思う。

・・・「得意でないところを語る」愚を犯す覚悟で言えば、普通の親には『料理』で説明してあげればいいんじゃないかな。
例えば、これは友瀬もわかる範囲なので、シンプルに『ご飯を炊く』ということを考えたとき。

1. 必要な量の米を準備する。
   • 適当に出すんじゃなくて、枡などできちんと計る。
2. 砥いで。
   • 無洗米なら研がなくていいかもしれない。
3. 適量の水と一緒に釜にいれ。
   • 米の量にあわせて。新米なら少なめ、古米なら多め、みたいな加減もして。
4. 火にかける。
   • はじめちょろちょろなかぱっぱ。
5. 炊き終わったら、しばらく蓋をしたまま蒸らす。
   • 赤子泣いても蓋とるな。

・・・こういうことを説明できることが、「作業の分析」であり「アルゴリズム作成」。
これができないと、お米は炊けない。

もちろん、おいしいご飯にするにはもっと具体的なことが必要なんだけど。
重要なのは、そこは「道具」他の環境で変わってくるところ。

例えば上記での「火にかける」工程。
大昔はここは竈とお釜の世界で。
前述の『はじめちょろちょろなかぱっぱ』の手順だとか、そもそも『薪に火をつけるには』とかが必要な知識だった。
でも今時の電気炊飯器を使って炊くなら、ここは『電源につなぐ』『スイッチを入れる』で十分で。
この道具の差が、PCでいうなら『アセンブラ』と『高級言語』の差みたいなものなんだよね。

道具の使い方は、もちろん必要な知識です。

道具の使い方を知らないと、例えば『ボタンを押せば三合のお米がでてくる』米びつを前に、枡で計量するような愚を犯すことになる。
Googるとでてくる『ダメコード』の原因の一つで、そういう不恰好は、避けたほうがいいのは間違いない。

だけど同時に、それはただの道具の使い方。
魂として重要なのは『三合分を準備する』ことであって、『３のボタンを押す』ことじゃない。
『コーディングだけ教える』のは『３のボタンを押す』と教えることになりがち。
もし将来『枡で米を計量する』しかない環境にであったとき『３のボタンがないから炊けない！』と詰まるのでは、困るわけです。

ご意見などがあれば。

何が問題なのかわからないと思うので、まずは状況解説。
構造化マネージャの編集エリアは、Windows標準の TextBox コントロールを使用しています。
これ自体には「ルーラー」なんて機能はないので、独自に追加描画する必要があります。
直感的に考えると、以下のような感じになりますよね？

• 「横スクロールが発生」したときに、描画する。
• 表示が何文字分スクロールしているかを取得し、それを「開始位置」として描画する。

ところが、ですね。

• 「横スクロールが発生した」というイベントは、TextBoxはサポートしてません。
• 横スクロール状態が『何文字分/何画素分』ずれているかも、TextBoxはサポートしていません。

仕方ないので、サポートされているモノを駆使して、以下のようにして実装しました。
後述するようにいくつかのアラがあるのですが、とりあえずは目をつぶっています。

• 「KeyUp（押されていたキーが離された）」イベントをトリガーにする。
  
  • スクロールは、「文字入力で桁が多くなった」「カーソルキーで横移動した」ときに起きるので。
  • ただ、マウスでの「長文テキストの貼り付け」「選択ドラッグ」など、いくつか逸脱する操作はある：そこへの追従が未完了。
• 「ズレ」量は、画素数情報から算出。
  • 以下の情報は、取得できる。
    • 現在のカーソル位置の、TextBox上の pixel座標
    • 現在のカーソル位置の、文字列内インデックス（テキストボックス内の全文字列のｎ文字目）
    • 現在のカーソルがある行の、先頭文字列のインデックス
    • 使用しているフォント（幅）
  • 上記の真ん中２つから「その行の先頭からカーソル位置までの文字数・文字列」がわかるので。
    結果、「その行が先頭から表示されていたとしたら、カーソル位置まで何画素必要か」がわかる。
    そしてそれと「カーソル位置の pixel座標」とを比較することで「何画素分、表示が短い」かがわかる。
    そしてその結果、フォント幅から、「何文字ずれて表示しているか」がわかる。

前述の通り、マウス操作などいくつかの条件で「ずれる」のは気づいていますが。
テキストエディタって本質的に「マウスを使わない」ことが多いので、とりあえずは妥協ですかね。

11/22 追記。
上記テキストで書いたことを図示。

ご意見などがあれば。

まず、その「いらっときた」敵がどういうモノか、説明します。
『それを倒すと、戦場にいるこちらのキャラ全員が、一定時間スキル使用禁止になる』というもの。
つまりこれを倒すと、それからしばらくの間『素殴り』でしか戦えない。

なぜこれにイラついたかというと、それは TEG の基本的なゲーム内容に相反するから、です。

TEG の基本ルールは、『敵の戦線突破を阻止しつつ、敵を全滅させる』のが目的です。
で、副次的な要素として、多くのイベントで『より早く倒したほうがボーナスが大きい』ルールが採用されています。

で、システム的に『敵を倒す』手段にはいくつかがあります：

1. 通常攻撃。
   • いわゆる『素殴り』。
     プレイヤーが何も操作をしなくても、味方キャラは手近な敵に突撃して攻撃をします。
     味方キャラは攻撃範囲にいる敵に対して、おおよそ1秒に1回攻撃を行います。 キャラによって多少の速度差はありますが。
     
2. 直接攻撃スキル。
   • プレイヤーが指示しなければ使用しない攻撃。
     固有の範囲内に文字通り「攻撃」を行うスキルです。
   • 使用するには「燃料」が必要ですが、その代わり攻撃力や範囲が通常攻撃より優れており。
     また「燃料がある限り時間を消費せずに使用できる」という特性があります。
3. 特殊なダメージスキル。
   • 例えば「敵に毒を与える」スキル。
     毒状態になった敵は、定期的にダメージを受ける。
   • 基本的には、上記「直接攻撃スキル」に付随。
     

上記を見ればわかるように、敵を『早く』倒すために重要なのは『直接攻撃スキル』です。
通常攻撃は「一定時間ごとに1回攻撃」なので、たとえ「一撃で倒せる」敵ばかりだったとしても、一定の時間がかかります。
その点、スキルは燃料がかかるものの、時間を節約できます。
一定量の燃料を費やして範囲殲滅するようなことが、効果的なのです。

もちろん、そういう「有利なもの」を制御するというのは、ゲームとしては必要なハードルです。
ですから例えば「スキル禁止状態にさせる」ような敵攻撃自体は、友瀬も否定しません。
ただそれは「超えられるハードル」であるべきで「突破できない壁」ではダメだと思うわけです。

例えばTEGでは「出現後4秒以内に倒せないと、スキル禁止してくる」敵がいます。
これは良いと思うのです：裏返せばこれは「4秒以内に倒せないとペナルティ」というハードルなのです。
プレイヤーはそのために頭を使います。
例えば「それを素早く倒すために、それにぶつけるための攻撃スキル（燃料）を温存する」とかするわけです。 そしてこれは「努力して、敵全滅までの時間を短縮する」方向性で、ベクトルが一致しています。
「ハードル」と言えるのです。

対して、「その敵を倒すとスキル禁止される」というのは違います。

ゲームメカニズム上「それを倒さない」という選択肢はなく、そしてそれは「十数秒続く停滞」の始まりです。
「うまく飛び越せれば時間短縮できるハードル」ではない。
「迂回してタイムを浪費するしかない壁」なのです。

事前に継続的な強化スキルを使って、スキルを使用できない間の殲滅を加速して対応、という手がありそうに思えますよね。
でも、出現する敵のほとんどは「素殴りでも1攻撃で倒せる」ようなものがほとんどで。
強化スキルは、ほとんどお飾りになることが多いのです。

まあ、ね。「インフレ対策」とか「ゲームのバリエーション」として仕方ないのはわかるのです。

初期の TEG では、スキルの多くは「直接攻撃」のものが主流。
「燃料」は味方陣地の量に比例して得られるものなので、ガス欠気味で。
スキルは、その支払い・収入を考えて、ここぞというところで使うものだった。

でもインフレの結果、「極端にコストの低い攻撃スキル」や「燃料生産スキル」が増えて。
条件は選ぶものの、最初から最後まで攻撃スキル連打でごり押しするようなことすら、可能になっている。
それがゲームとして健全かと言われたら、決してそうじゃない。

でもそれへの対策が「回避できない・全キャラのスキル禁止」といわれると、違うだろ、なんですよ。

例えば、こんなんだったら、多少はマシだと思います。

• その敵を倒したキャラのみ、スキル封印される。
  • 5人の編成に複数の攻撃スキル利用者を組み込むような、戦略的対応が可能になるわけです。
• そういう敵が一度しか出ない。
  • これも類似。
    「全体封印」が行われるまで一部の戦力だけで戦って、封印後「きれいな第二陣」を出して対応。
• 回復系の能力で、封印される時間を短縮できる。
  • 例えば事前展開の「回復フィールド」などで、回復1回につき封印時間も1割減るとか。
    スキルだとそれも封印されているので（笑）
• 倒した際のダメージ量で、封印時間が変わる。
  • 素殴りで倒せばせいぜい数秒の沈黙だが、「5倍火力」のスキルなら5倍==10秒以上の沈黙に。
    これがわかっていれば、スキルを使わずに倒す選択肢がでる。
    「大火力スキル」へのアンチテーゼにもなる。
    

まあ、いずれも妨害には違いないので「いらっ」とこないとはいいませんが、まだマシだよね、という感じ。

ご意見などがあれば。

テクノロジーの最初期は「それのエキスパート==使える＆中身も知っている」。
だけどそれが一般化することで「使える（だけの）エキスパート」が主流になる。
これ、今までも何度もあったことだと思う。

例えば自動車はそうだし、PCもそう。
ラジオなんかもそうだよね：真空管とかちょっとした半田付けで修理していた時代もあるけど、 今の電子機器はそんなかんたんにはいじれない。

これには「入れ子的」な観点もあります。

PCの世界でも、「Microsoftの人」は Windowsのエキスパートではあるだろうけど、PCハードウェアの「作り方」までは知らない。
そーゆーのは「Intel入ってる」の人の仕事。

ただともあれ「なにかの一介のユーザ」は必ずしもコアなことは知らなくても問題なくて。
でも「ベンダーはコアなことを知っている」ことが期待されている。
そんなことが、一般的だと思います。

だからまあ、まだ「ユーザだった」新社員がいたって、なんの不思議もないかな。
そこからエキスパートになれるかどうかは、また別の問題として。

ただ・・・ですね。
実は最近、人気のとある技術が、この観点に関わって気になっています。
「AI」です。

昨今の AI は、ニューラルネットワークを使っています。
これ、ある意味で「究極のブラックボックス」なんです。

例えば「将棋のプログラム」。
以前は、開発者が思考アルゴリズムを考えて練り上げていくものでした。
だから「将棋に強い開発者が作らなくちゃ」みたいな話もあった。
別の言い方をすると、膨大な計算能力によるギャップさえ考慮しなければ、開発者は「プログラムがどういう手を打つか、論理的に予測できる」ものといえるわけです。

対して、昨今の将棋AIは、ちょっと違います。
大量の戦況・好手・悪手の情報を与えることで、AIが「似たような状況で何が好手なのか」を学習していく。
開発者は個々の細胞の「学習のメカニズム」や「学習の内容がどうなっていればどう動くのか」は知っていても。
無数にある細胞同士が「実際に何を学習したのか」「複数がどう関係しているのか」はまず把握できない。

・・・別の言い方をすると、ですね。

従来のプログラムは、「将棋の思考アルゴリズム」そのものを開発していた。
現在のAIは、「学習の仕方」だけを開発していて、「思考アルゴリズム」はAIが勝手に作っている。

・・・怖いわけですよ。
最初のほうの話で言えば、たとえ開発者であっても「作りを知らない」状況になっている。
なんらかの理由で AIがその細胞の一部だけでも失うと。
元のAIを再構築できるかというと、まず無理。

もちろん、AI開発者がこれを知らないわけはないですから、 バックアップなどの多数の手は打っているでしょうが。

ご意見などがあれば。

出発点がなんだったか、というと、『セクション内容の別窓での表示』です。

構造化エディタの弱点の一つに、多くのエディタで持っている「分割表示」がないことが挙げられます。
セクション管理によって全貌を見渡すのは得意なんですが。
「メソッドAとメソッドBを見比べながらいじる」みたいなことができない。

これの解決策の一つとして、
『セクションツリーで ALT＋Enter」すると、そのセクションを別窓で開く』というような機能を考えていました。
で。その「別窓」で何ができればよいか、本窓との関係はどうしよう・・・と考えていたところで、気づいたのです。

別窓で開くのは『ツリー構造を持たない１セクション』なので。
そこで期待される振る舞いというのは、『普通のテキストエディタ』なんですね。
だとしたら、独自のエディタを使わなくても例えば秀丸などの『外部エディタ』を使ってもいいんじゃないか？
そうすると、そういう『既存エディタの高度な編集機能』を労せず利用できるわけですし。

というわけで、以下もやっと仕様を考えてみた。

• 友瀬Stedは、既存のSted同様の「ツリー＋エディタ」の２ペイン構成。
  • Sted同様の、ツリー構造の管理機能や多少の編集機能は持っている。
• 機能仕様：セクションの外部編集。
  • ツリーのセクションを『ダブルクリック』or『ALT+Enter』すると、そのセクション部分だけを含んだ『テキストエディタ』が起動される。
  • この『外部エディタ』が開いている最中、Sted側ではそのセクションは一切編集できない。
    • セクションの内容のテキストを編集できない。
    • そのセクションに関わる、ツリー構造編集（そのセクションの削除や分割・結合）も実施できない。
  • 外部エディタ側で「保存」すると、そこでの編集結果が Sted側セクションに反映される。
  • この『外部エディタ』は、１つのセクションにつき１つ開くことができる。
    つまり、複数のセクションを並べて表示できる。
• 設計仕様
  • Stedは、対象となるセクション「だけ」を書き込んだ一時ファイルを作成し、それを外部エディタに渡して起動させる。
  • Stedは当該ファイルを監視し、その時刻が変わったらセクションに反映する。
  • Stedは当該外部エディタ窓を監視し、それが閉じたら「対応セクションの編集を許可」に戻す。

このやり方は『単セクションの編集』を外部に委託する形。
当然外部は『セクション構造』なんてのは一切考える必要はない。
sted側は、『複数のセクション』を意識する・管理するための機能が必須要件。
だから『マネージャ』。
セクションの追加・分割・結合・削除。
複数セクションをまたがった検索。
タイトル行。
・・・あたりかな。

わりとスジよさそうなので、ちょっとこの方針で検討継続。

ご意見などがあれば。

つーわけで、ちんたら作業はしてます。

AIR時代のソースコードは前のPCがクラッシュしたときに失われているので、一から開発状態。
以前は無限回Undo とか実装した記憶があるんだけど、どうやって作ってたかな（笑）

で、実はこの Undo/Redo 仕様が、構造化エディタ開発の肝だと思ってます。

元sted では「ツリー側で1回」「テキスト側で1回」のUndo枠を持っていました。
ある意味わかりやすいのですが、エディタとしてはやっぱり弱いんですよね。

ただ同時に、この仕様にしている理由もわかるんですよ。
sted 特有の特性から、ちょっと踏み込むと『独自でのUndoメカニズム』を作らなくてはならなくなるのです。

以下、具体的な事例。

• 単純に「ツリーペイン」と「テキストペイン」とのUndo/Redoを考えなければならない。
  • 例えば「１つめのセクションでたくさん編集」「次セクション追加」「1文字入力」
    ・・・と、ここで Undo 操作を3回使うとどうなるか。
• セクション分割(Shift+F9,Shift+F10など)
  • 元stedでは、一切Undo機能なし。
  • 面倒な理由：この操作は、『テキスト編集エリア』と『ツリーエリア』の両方を同時に編集している、ということ。
    
    • わかりますよね：ざっくりというと
      『現在の編集エリア、後半部分をクリップボードにいれながら、削除』
      『ツリーに新しいセクション追加』
      『追加セクションに、クリップボードの内容コピー』
      ・・・という動作を行ったのとほぼ同様なのです。

とまあ、いろいろある感じ。

どこまでやるかもわからないですし、それも含めて、 公開するかもわからんですけどね（笑）

ご意見などがあれば。

で、ちと思い立って Googleの画像検索をしてみました。

結論から言うと、汚染は多少おきていて。
でも、うまく住み分けができた形、とはいえるかも。

ん〜・・・口で言うよりは、実物を見てもらったほうがいいかな。
以下、Google検索へのリンクを並べてみます。

まずは 『木枯らし』で検索。

次、 『コガラシ』で検索。

・・・ひどい（笑）

ご意見などがあれば。