FOT.Time の取説をざっと整理したら、また色々手を入れたくなる場所が見つかってくるというエンドレス。
「ソースにはコメントを書け」という大切な言葉がありますが、じゃあ何を書けばいいのかというと、
中身の説明なら関数そのものを見てもらえばいいわけで、見て分からないような関数ならコメント書く前にプログラムに手を入れたい。
ソースの中にコメントを書く代わりに、他人が中身を知らないでも使える程度に整理された取説、
平たく言うと「そのプログラムの仕様書」を、コメントではなく外部に書けば、それが一番しっくりくる。
どうせ整合性取らなならんのは変わらんし、ソース見て手を入れてる最中にコメント書き直しなんて作業を割り込ませてたら何もできんし。
HTMLでテーブル表示されてる値を範囲選択してコピーして、エディタに貼り付ける。
Operaだとタブ区切りでコピーされるから、エディタに貼っても編集しやすいし、Excelでもそのまま使える。
FFXI戦闘スキル表なんかは、この動作を前提に作ってある。
IE9は割と意味が分からん動作をする。セルごとに改行されて、改行区切りになる。
まあ、エディタで改行をタブに置換してから、タブ3つを改行に置換し直せばそれで行ごとに戻せる。
Firefoxは理解不能だった。セルも行も区切りが一切存在しない。どういう意図でこの仕様になったのか全く分からない。
いくらなんでもこれはひどい。わたしはメインで使ってるわけじゃないから問題にならないけど、
メインにしてる人ならさすがにこれは誰かしら改善要望を出してるだろうと思うんだが。
ひょっとして、Firefoxって普及率自体は高くても、メインで使ってる人となると相当マイノリティなんだろうか…。
DOMの操作で parent_elm.appendChild(child_elm) とすると、parent_elm の子要素として child_elm が末尾に追加され、戻り値として child_elm が返る。
で、普通なら別にどうということはないんだけれども。
child_elm として DocumentFragment を渡すと、空になった DocumentFragment が返ってきて困ったという話。
言われてみれば全く想定通りの挙動であって、別に何ら不思議はないんだけれども。
HTML を構築するのに、たとえば
<table>
<thead><tr><td>A</td><td colspan="2">B</td></tr></thead>
<tbody><tr><td>X</td><td>Y</td><td>Z</td></tr></tbody>
</table>
であれば
var table = dce("table");
table.push("thead").push("tr").push("td", { textContent : "A" }).chain("td", { colSpan : 2, textContent : "B" });
table.push("tbody").push("tr").push("td", { textContent : "X" }).chain("td", { textContent : "Y" }).chain("td", { textContent : "Z" });
こんな感じで組み立ててるわたしからすると、push( = appendChild )した結果として、空の DocumentFragment が返ってくるようでは、
その直後には chain( = parentNode.appendChild )ができないってことで、さてどうしようかと考え中。たら解決した。
parent_elm.appendChild(child_elm) のあと、appendChild の戻り値の代わりに parent_elm.lastChild を返せばいいのか。
構想何年になるんだかもはや分かりませんが、自分が欲しいマインスイーパーをデッチあげてみました。
製作開始が週末からだから、ざっと1週間か。テストプレイ分引いて、基礎作成＆機能追加＆バランス調整のコーディング作業だけで言えば3日程度かなぁ。
作業内容はだいたい運転中とかに頭の中でまとめてたから、逆にこれを3日で作れと言われたって無理だけれども。
自分が欲しいものを作っただけあって、自分でプレイしているだけでも結構満足なんですが、
とりあえず完成させるためにペタペタとコピペしまくったソースを、これからどんどん処理していけるかと思うと楽しみです(謎)
機能拡張の余地は有り余ってるので、整理が終わったらのんびりいろいろやっていきます。
ボムの追加や得点計算は、できる限りシンプルにしたつもり。
ゲーム性を損なわない程度の難易度で、かつ無理ゲになりすぎないように上限を決めたつもりですが、
それでも33.5%だと5行確定での現状維持が限界なんじゃないかなぁ。30%超10行以上は無理ゲだと思う(笑)
はっきり言って25%(ボム6個)超えたあたりでメチャメチャつらい。
ボム4つある状態で15行確定のボム7個とかやると、びっくりするほど開きません。
この辺、ボムによる機雷率の算定をどう緩和するか考え中。確定行数での増加分は反映したいんだけれども。
高得点を出す秘訣は、ボムを増やしすぎないようにどんどん使うことです。 かといって少なすぎると気を抜いたとたんに食らいボムで0になって詰むかもしれませんが(笑) 他には、余ったマークで全部マーキングして確定してしまうとかの、このルールならではの定石を覚えることとか。
テストプレイの限りでは、ざっと500点ぐらいが一つの山かなぁ。
1000点目指してみても、500点超えたあたりで疲れてプレイが適当になって、機雷踏んで点数半減して凹みます。
普通にプレイしてコンスタントに1000点越えられるなら、相当集中力がある人でしょうね。
わたしはよほど調子よく進まないと超えられません。
なお、ボム無限等のチート系機能は、「ただの暇潰し」という当初の目的と全く方向性が違うので作りません。
そもそもブラウザのデバッグ機能やユーザースクリプトなどを使えば、各パネルの機雷の有無ぐらいは簡単に判別可能です。
そーいうのがやりたいなら勝手にやっててくださいってことで。
変数名を適切なものに置換しつつ、処理の関数切り分けやら順序の見直しやらといった大幅変更作業。
外部の意識を絶つためにヘッドホンでBGM流しっぱ。
テストプレイと称するマインスイーパーもちゃんと楽しいんだけれども。
やっぱ趣味プログラムはこの変更作業が一番楽しいな！ｗ
スペカつええな！(笑)
自分で作っといて何だけど、機雷率25%の10行を平気で抜けるとか意味分からん(笑)
Lunaは×1.5でも低いかと思ってたけど、軽く1万点超えるとなると高すぎだな。機雷率を上げるか倍率下げるか。
他キャラのスペカどうするかなぁ。
何か思い付くネタってーと…。
マインスイーパーをいじっていたと思ったらjavascriptの動的読み込みを作っていた。
な、何を（ｒｙ
ライブラリ全部のonloadを待ってから実行…。
それはどーなんだと思わなくもない。
テストプレイのやり過ぎで、マインスイーパーの難易度が分からなくなってきた。
「あれ、Lunaだよな？」とか思いながらHardぐらいの感覚でやるようになってしまったので、ちょっと底上げ。