いえ、ものすごく単純に。
もともとこのページは「未整理のモノ」を置くために作ったものなので、ある程度まとまったら表に出すというのが、本来の姿でもありますし。

そういうことも含めて、Junkyardは検索除けもしているわけですし。

そういう基本に立ち戻ると、プレイエイドとかいくつか表に移動すべきネタもあります。

まあ、表に出すとそれ相応の手間は増えそうなので、このままという選択肢もそれなりにあるんですが・・・ちょっと考えてみますかね。

ご意見などがあれば。

とりあえず、ここがわかりやすいかな。

svg要素の基本的な使い方まとめ
http://defghi1977.html.xdomain.jp/tech/svgMemo/svgMemo_01.htm

仕様・リファレンス的なのがこちら。

http://memopad.bitter.jp/w3c/svg/default.html

https://triple-underscore.github.io/SVG11/

単純にいってしまうと、xmlで座標データをいろいろと書くと、その通りに表示されるというもの。
2017年現在では、多くのブラウザでサポートされていて、問題なく表示されている。

例えば、こんな感じの xmlを埋め込む。

<svg xmlns="http://www.w3.org/2000/svg" width="200" height="50" viewBox="0 0 200 50">
<line x1="10" y1="10" x2="10" y2="40" style="stroke:rgb(0,0,0);stroke-width:2" />
<line x1="10" y1="40" x2="190" y2="40" style="stroke:rgb(0,0,0);stroke-width:2" />
<polyline points="10,25 100,19 190,10 " style="fill:none;stroke:rgb(255,0,0);stroke-width:2" />
</svg>

とりあえず検証した結果としては、まあ意図する用途では使えそう、かな。
規格的にはどんな絵でも描けそう、というか Illustratorとかでもデータ吐き出しできるっぽいので、凝った絵も描ける。
ただ、著作権的意味で、普通のイラスト的な使い方には課題はあるような感じはする。

著作権フリーで出してよいもの限定、とすべきかな。

• ベクターデータなので、低解像度で公開するようなことができない。
  • 特に svg では実データと表示座標系を独立コントロールできるので。
    表示系を大きくすれば、ものすごいサイズに拡大できるし、画質劣化も原則ない。
    • 線の太さは固定なので、相対的に線画が細くなるような部分はある。
• 『SAMPLE』というようないわゆるウォーターマークをかぶせることができない。
  
  • かぶせること自体は、もちろん可能なんだけど。
    全データが xml的に公開状態なので、その『SAMPLE』部分だけを探して削除することで元絵だけを取り出し得る。
  • 普通のjpg画像とかだったら『SAMPLE』文字部分が『データとして存在しない』んですよね。
• 例えば『著作者サイン』部分のデータを発見することができれば、それを削除することもできる。
  『偽物サイン』を上書き・追加することもできる。

プラグイン化もちょこちょこ進めていまして、これくらいのことはできるようになっています。

ちなみに、動的生成にこだわっているわけは、手間に関わることです。

前述の通り、画像は「別途作って貼ればいい」とは言いましたが。
正直、ペイントツールを使うまでもないんだけどなー、というタイプの絵ってありますし。
なにより、手間がかかるので避けたいケースってのがあるんですよ。

前述の体重管理なんてのは典型です。
やりたいのは、下記のようなシンプルな条件です。

• 毎日、１つずつデータが増える。
• 作業的には機械的に「前日値→今日値」の線を引くだけ。

・・・これを実現するために。

1. Excel 立ち上げる。
2. 列に値１つ追加。
3. グラフの「更新」実行。
4. グラフ部分をファイルに保存。
5. ブログにファイル貼り付け＆旧情報削除。 と、やることが必要になります。
   

・・・すげー面倒。
動的生成が可能になれば、上記の２つめの手順：『列に１つ追加』の作業をブラウザ上でするだけでいいわけです。
簡単じゃないですか。

・・・まあ、その分事前準備がいる、ってわけですけどね（＾＾；；

ご意見などがあれば。

• 確認。 -- ともせ％管理人。 2017-03-18 (土) 00:27:36

今後どれだけ使うかはわかりませんが、今までにも文中でときどき「A⇒B」みたいな表現は使っていたので。
ちょっと試してみる、って感じです。

ぶっちゃけ、画像描いて添付したほうが早いケースもあるような気もしますが（笑）

とりあえず、dot言語についていろいろまとめてあるサイトを自分メモ。

Graphvizとdot言語でグラフを描く方法のまとめ
http://qiita.com/rubytomato@github/items/51779135bc4b77c8c20d

ご意見などがあれば。

基本分析。†

M:tG では、もともと『相手の体力20点を削りきったら勝ち』という勝利条件がありました。
で、『毒』は、M:tG の拡大の過程で追加された『新しい勝利条件』の１つです。

体力との対比も含めて、以下に記載してみます。

• 勝ちに至るには
  • 体力/ダメージという手段では、相手に対して『20ダメージ』を与えることが必要です。
  • 毒では、毒カウンターを『10個』与えると勝ちです。
    • 上記からよく『毒1個は2ダメージに相当する』といわれていました。
    • とはいえ、毒と体力はあくまで別のパラメータとして管理されるので。
      最悪『19ダメージ』＋『毒9個』を与えても、勝てません。
• それを相手に与えるには。
  • 毒は、極めて稀な例外を除けば、すべて『毒を与える能力をもつユニット』による攻撃でのみ、相手に与えられます。
  • ダメージは、極めて多彩な手段があります。
    毒同様の『ユニットからの攻撃』はもちろん、直接的な攻撃魔法や、エンチャントによるダメージなど、実に多彩。
• 防御・回復手段。
  • ダメージは、それに対抗する防御手段もまた、多数あります。
    • 例えば、ダメージを受けないように事前に防御壁を作るような『軽減』。
      例えば、受けてしまった傷を癒す『回復』といった手段です。
  • 毒は、これも極めて稀な例外を除けば、取り除く手段がありません。

簡単に言ってしまえば、『わりと簡単に攻防・増減がおきる体力』『与えづらいが、一度通れば防御もしづらい毒』という感じでしょうか。

歴史的な話。†

毒は、M:tGのシステムとしては割と古いものなのですが。
トーナメントレベルに至るまで、紆余曲折していた歴史があります。

その状況をメモ。

• 黎明期
  • クリーチャーの能力に言葉で『相手にダメージを与えたら毒１個』『攻撃してブロックされなかったら毒1個』というように、書かれていた時代。
  • 総じて『弱い』評価をされていた。
    理由を以下列挙：
  • この能力自体は、他のクリーチャーに影響を与えられない。
    しかしこの能力を持つクリーチャーは、その『毒』能力の分、コストに対する（従来からのダメージとなる）攻撃力が低い。
  • 突破できても置ける毒は1個が普通。
    そのため対プレイヤーとしてみても、実質的に『攻撃力２の一般的な軽量級』と同じ攻撃力しかない。
    • 端的にいうと、普通の攻撃力２クリーチャーをだすのと、毒１・攻撃力１のクリーチャーとが、コストでは同じレベル。
      どちらも『10回突破できれば相手を倒せる』という意味で、対プレイヤー攻撃力は互角。
      そして毒クリーチャーは「同コストのクリーチャー」に戦闘で負ける。
      ・・・これは、うれしくない。
    • やや大きい『攻撃力３、毒１』というクリーチャーもいたが、それだと『毒よりも先にダメージで倒す』結果になってしまうので・・・
    • とはいえ、これは『毒とダメージの両天秤』ができるということで、悪い話ではない。
      相手が『超回復デッキ』なら毒で倒せるわけなのだから。
  • 『ダメージならなんでもよい』タイプのクリーチャーが何種類かおり、射撃能力を与えるカードとのコンボは有力だった。
    というか、トーナメント級ではこのタイプだけが有力だった。
• 『有毒』期
  • キーワード『有毒ｘ』で表現。攻撃してダメージを与えたらｘ個の毒を置ける。
  • 毒を与える能力としては、黎明期とあまり変わっていない。
    だが、この時期のカードはコスト面で大きく改善されており、それによって有力候補となっていた。
  • 特に、このキーワードが『スリヴァー』という能力コピー種族に付けられたのが大きく、当時のメタの一角になっていた。
    • スリヴァーというのは種族の名前で、場に出ているすべての同族とキーワード能力を共有する、という特性がある。
      結果、『有毒』を持つスリヴァーが1体出現すると、場のすべてのスリヴァーが『有毒』となった。
      この『コピー』は無料なので、コスト的にお得なわけだ。
    • ついでにいうと、その『有毒もちスリヴァー』自体が、コスト１・攻撃力１・有毒１と、他のコスト１クリーチャーと比較しても悪くなかった。
      なにしろ、黎明期は『攻撃力１・毒１でコスト３』とかだったので。
    • 前述の『毒前にダメージで勝つ』ケースもあるにはあった。
• 『感染』期
  • キーワード『感染』で表現。これを持つと、攻撃ダメージを通常のダメージではなく毒カウンターとする。
    • 過去の毒能力は『一度に１，２個』与えるのがやっとだったところ、感染では『攻撃力と同じ』になったため、大きくなりやすくなった。
      例えば巨大化/GiantGrowth で攻撃力+3、とかできるわけだ。
    • 代わりに、通常のダメージは与えられなくなった。
      『毒殺』目的だけなら大した問題ではないが、例えば『毒とダメージでの両天秤』ができないとか、相手の『自傷する代わりに強い魔法』への抑止力がなくなるなどの問題が。
  • さらにこのキーワードでは、対クリーチャーでもダメージではなく『-1/-1カウンター』を与えるという、通常のダメージより有利な特性となっている。

ざっくりまとめると、コスト的にも能力的にも弱かった黎明期を反省に。
コスト的に見直したのが『有毒』時期。
強化しつつ、他の効果との相互作用が生まれるように改善したのが『感染』、かな。

とりあえず、こんな感じ。

ご意見などがあれば。

いちおー、はっぴーばーすでー、俺（笑）

ご意見などがあれば。

一応簡単にチェックはしましたが、どこかで問題があるかもしれません。

何かお気づきなら、連絡ください。

ご意見などがあれば。

例えば、先日作った pageinfo プラグインは、人間が作成した『pukiwiki書式の記事』からタイトルや概要を作り出すものです。
その処理上、プラグインが呼び出される度に、元記事データを検索したり加工したりしています。
結構複雑な条件が必要なので、この検索には正規表現を利用しています。

正規表現でのマッチング処理は、どうしても負荷がかかる・処理が重い機能なので、本当は回数をあまりやりたくない。
で、このプラグインの場合原理上、『元記事の変更がなければ、何度やっても結果は同じ』です。
・・・何度やっても同じなのに、毎回正規表現処理ってのはちょっと筋が悪い。

なので、こんな処理をプラグインの先頭にいれるのはアリかな、と思っているわけです。

• 呼び出されたら、「元データ」に対応するキャッシュがあるか否かチェック。
  • キャッシュがなければ仕方ないので、普通の生成処理開始。
• キャッシュがあるなら、「元データ」と「キャッシュ」の更新時刻を確認。
  もしキャッシュのほうが古ければそれは使えないので、普通の生成処理開始。
• この状態ならキャッシュのほうを使う。

プレビューモードのときは「元ファイルが変わってない」のでキャッシュは使えないとか。
はキャッシュといっても実態的にはファイル保存することになるので、そのアクセスと計算、どっちが『高価』か検証が必要とか。
いくつか条件がありそうですが。

少なくとも pageinfo に限って言えば、これはもともと「元Wikiデータファイル」を読みだして正規表現加工しているので。
「加工済のキャッシュ」を読み出すならば、正規表現分は確実に軽くなるので、余地はありそうです。

同じような話で。
先週の土日で、日記一覧のカレンダーに土日・休祝日対応を入れました。
これ、いわゆる万年カレンダーのアルゴリズムを使って計算していますが、結構複雑です：特に「ハッピーマンデー法」に関わる計算が面倒。
「日曜に休日がきたら、翌日に繰越」とか。
「いわゆる飛び石連休の間も休みになる」とか。
ある日が休日になるかどうかを知るために、その前後の日の休み状況とかまで調べることになるわけです。

・・・これを「カレンダー表示のたびに」計算するってのは、ちょっとマヌケです。
曜日・祝休日の過去の状況なんてのは、一度決まったら確定して変わらないものですから。
一度表示のために作成したら、それを保存しておいたほうが効率がよさそう。

まあこちらの場合、カレンダー計算はすべてメモリ上なので、ファイルアクセス時間を考えると微妙なところもありそう。
ん〜・・・こっちはやるなら、スケジューラ的なものと組み合わせる感じかな。

ご意見などがあれば。

以下、わりとまとまり無く散文的に。

第一候補：多人数戦向けキャラ。†

一口に多人数戦向けといっても、いろんなタイプが考えられます。
ざっくりというと『直接or間接』ｘ『攻撃的or防御的』の組み合わせ４パターンか。

• 直接・攻撃的な事例：味方を踏み台に使う。
  • 動的・静的な差はある。
  • 例：キャプ翼「立花兄弟」のスカイラブハリケーン的「動的」タイプ。
    
    • これは、両方のキャラの息が合わないとならないので難しそう。
      つーか、これやるなら専用チーム2人分を作りたい。
  • 例：かがんだ味方の背を利用してハイジャンプ⇒攻撃とか。
    SOAアニメ2期でユウキがやってたりします。
    • これは静的：前のキャラはただ『いる』だけでよい。
  • いずれにせよ、これは『パートナー戦闘』向けかな。
    後列にいたキャラが前列にでてくる手番で、特殊なことができる。
• 直接・防御的な事例：カバーリング。
  • 『マルチプレイ』向けの仕組み。
    マルチプレイでは、1人側は『複数いる相手のうち、任意の相手1人を選んでダメージを与える』ようになっているが。
    ここで、欄外コメントで『この手番はこのキャラを得点対象にしなければならない』と指定するようなもの。
    
  • 逆のパターンもできるだろう。
    『黒子のバスケ』的な『ターゲットにならない』というたぐい。
• 間接・攻撃的な例：攻撃支援魔法的なもの。
  • いわゆる祝福系の魔法がわかりやすい例。
• 間接・防御的な例：これも支援魔法系。
  • バリア類はそうね。
  • 例えば『踏み込んだ足元を撃つ』ことで、相手の攻撃キャンセルとか。

どうあれ、一般に多人数側に有利なはずなので、単体だと弱めのキャラにするようなバランス調整はいるかも。

超呪いキャラ。†

これは以前にも書いたかな。

攻撃がほとんど『S』判定で、ダメージは与えられないが x回ヒットさせたら勝ち、というタイプ。

もやもやと検討は続けていまして。
これのバリエーションで以下のようなものも考えています。

• 一定回数相手にヒットすると、行動が変わるタイプ。
  • ある意味、HJ版の沼地の女王に近い。
    あれも『事前の呪い2発』を前提に一撃必殺技が使えるようになっている。
• 一定回数『被弾』したら、行動が変わるタイプ。
  • 逆転性が上がるのがメリット。

精霊使い的なの。†

『幻術使い』や『呪符使い』でも多少表現した、サブユニットを持つキャラ。
具体的には、以前に考えた『同行者』システムを使う。

これも、以前に検討した通り、多人数プレイを想定しているネタなので。
最初の多人数戦闘と絡めるかも。

とりあえずはこんな感じ？

ご意見などがあれば。

まあ、予想通りと言えば、それ以上のコメントもないよな〜。

FujiFilm自体、このカメラ後継機、2世代目までが限界だったし。

3DS的立体視デバイス、こっそり確保しておかないとダメかなぁ。

ご意見などがあれば。

「topicpath」」は、要はページの階層化管理をするのに適したプラグイン。
例えば、上記「日記」部分をリンクすると、「日記」というページにいく。

・・・この場合、問題として。
上記でいえば「日記」というページがないと困るわけです。
そして友瀬が直面したのが pukiwiki関連のページ。
例えば、友瀬が作ったプラグインは「pukiwikiプラグイン/tbsend」というようなページ名になっています。
そうすると、プラグインは「pukiwikiプラグイン」というページの存在を期待するわけですが。
現状友瀬のページ構成では、ここは「pukiwiki関連。」というページになっているわけです。
友瀬のサイト構成がイケてない、といえばそれまでですが （＾＾；；；

ともあれ、こういう事情から。
「pukiwikiプラグイン」というページを表示しようとしたら、代わりに「pukikiwi関連。」ページを表示する。
そういう振る舞いをする仕組みが、友瀬的に必要になったわけです。

で。pukiwiki にはこれに対応する仕組みとして autoalias という機能があります。
事前に「xxxxという文字列は、yyyyへのリンクとして扱う」というような登録をしておくと、システム側が常に・自動的にリンクをしてくれる機能です。
これによって、先の例であれば「pukiwikiプラグイン」というページ名を「pukiwiki関連。」へのリンクにできるわけです。

これの採用を考えてみたのですが、結局あきらめました。
理由は、この仕様自体がちょっと無理がある気がしているためです。
どういうことかというと・・・記事内に「pukiwikiプラグイン」という文字列を書いたとき、 それが常に「友瀬のサイトの pukiwiki関連ページへのリンクが期待されるのか」と問われたら、違うから。

例えば、
『pukiwiki 公式の pukiwikiプラグインページには〜〜』という文章を書いたとき。
もしここにリンクを置くなら、期待されるのは公式ページへのリンクです。
また、例えば、
『一般的に、pukiwikiプラグインには次のような特徴があります』・・・というような文章では。
ここにリンクをおく必要は、まったくない。

というわけで、別手段として alias プラグインを選択しています。
これは、普通のプラグインと同じように任意ページに記載しておくことで。
『そのページ（プラグイン）を表示しようとしたら、直ちにプラグインで指定された他ページを開く』というものです。

ただ、これ、公式ページにあるものは辿れない状態になってまして。
しかたなく、フルスクラッチしました（笑） 近いうちにこれも公開しようと思います。

ご意見などがあれば。

最初にスタンスの明確化。†

このJunkyard のような「事実上一般書き込み不可能」なサイトはともかく。
wikiシステムは本来「誰でも編集可能」なので、ある程度のいたずらは宿命的課題です。

ただ、トラックバック送信は『外部サイトにも影響』するので。
「しかたない」「運用ルールまかせ」というのはさすがに無責任で、多少の配慮が必要と考えて作成しました。

トラックバック送信まわり。†

送信プラグインの問題は、他サイトに大量のトラックバックを撃つ話がメインだと考えています。
それを抑止するための手段が、必要です。

とりあえず現状いれてある対策は以下のもの。

1. そもそも送信は、当該ページの編集権限がないと実行できない。
   • そのため、例えばこのJunkyardのような Wikiでは、いたずらできない。
2. １つのプラグイン記載からは1回しか送らない。
   • ボタンを押すと送信⇒ボタンが消えるので、再度wiki編集しないと送信できない。
3. １つのページからの送信は、1分に1回まで。
   • これによって、例えば「1ページに一度に多量のtbsendを書き込んで、順にボタンを押す」ような多量送信の試みが難しくなる。

これだけやってあれば、まあ大丈夫かな、という感じですかね。

やろうと思えば、「即送信しないで一度バッファリング、管理者が承認」というようなことも可能ですが。
それは現状は、なし。

受信トラックバックのスパム†

受信に関する問題の１つが、トラックバックスパムへの対応方法。
現状で「管理者承認」「一方的リンクの拒否」を実装済みです。
スパムを送る側からいうと「わざわざこちらのURLをスパム記事に埋め込む」ほうが面倒なはずで。
その意味で、上記「一方的リンク拒否」でわりと十分そうではありますが。

いわゆる「スパムフィルタ」とか「ブラックリスト」は、考慮する余地はあるかも。

ページのリネームまわり。†

受信したトラックバックは、当該ページの名称にヒモ付けて保存されています。
ヒモ付けというか、まったく同じファイル名で trackback フォルダに保存している。

この結果、pukiwiki の rename 機能で「元ページ」をリネームした場合、「対応するトラックバック情報ファイル」のほうのリネームはなされないため、ヒモ付けが外れてしまう、という問題があります。

rename 機能（プラグイン）のほうに機能追加すれば、対応はできるはずですが。
まだそこまで調べてません（＾＾；；

ご意見などがあれば。

• メモ。
  rename プラグインを調べたところ、plugin_rename_get_files() の最初のほうをいじればよさそう。
  つーか、そもそもrename 自体が今回のような「プラグイン管理化でページ対応したファイルを作る」ことを想定して準備してあるっぽいです。 -- ともせ％管理人。 2017-03-02 21:42:25 (木)