【Ｓｈｉｓａｋ Ｓｈｉｋｏｒｏ】 比類なき阿呆。

　はい、できました。

　http://www.interq.or.jp/earth/msym/nscr/nscr_defmake.html

　というかね、もうこれで勘弁してください的なものが。
　対応してない命令多いけど、引数が面倒だったりするものが多いので。
　複数指定できるような、例えばeffectなんて自分で書いてくれよ、とorz
　同様の理由で、組みかけていたdimを破棄したのは秘密。

　ファイル名拾ってくるのなんて、で拾ってくるのがいいんだろうけど、相対フォルダ構造の取り方なんざ、考えただけで脳汁垂れます。
　基準フォルダを手動入力せて、stringで抽出ってのも考えたが。
　めんどいな。
　組むのもめんどいが、使う方も面倒だろうと思うﾏﾁｶﾞｲﾅｲ。

　まぁ、終わったからいいかぁ…。
　バージョンアップや改訂は考えていません。気分次第。

　むぅ、右クリックメニューが手ごわい…。
　とゆーか、プログラムのセンスが無いだけかもしれない…。
　まさに、
　プログラムは、意図した通りではなく、書いたとおりに動く
　という状況です。挫けそうかも。
　いや、ベタ書きすりゃあ多分いけるんでしょうが…。
　こうなるぁ~~意地だじょ。
　超素人の面目にかけて、なんとか完成させてやるるるるるるｒ。

　あ、
　document.form.element[n].checked == true
　は結局導入しました。
　書いてみたら、こっちの方が楽だったのだわ（笑）。

　htmlソースが２０キロバイト超えました。
　グループ化してるラジオボタンの値取って来るのが面倒だね…コレ。
　onClickでハンドルしてるから、checked以外にチェック入れた状態でリロードすると、チェック入れてるにもかかわらず値が破棄されてしまうという…。

　document.form.radio[i].checked == true

　↑で取れば解決なんだけど、ボタンの数だけ処理組まなきゃならない（コードが増える）から面倒だわ。for文で配列を放り込んでもいいんだけど、そこまで熱、入れてないし。よってパス。
　まぁ、「リロード後の動作に注意〜」って書いておけばいいかなと。
　要望があれば直すけど、たぶんそんな要望はこねーだろーしｗ

　さて、一番面倒な「右クリックの動作」に取り掛かりましょうかねぇ。
　実はあんまり面倒でもないけど、書く気がおきないんだ…いや、やっぱ面倒かな…。不正な値や組み合わせを弾くようにしたいけど、今はそこまでする熱意がありませんので。
　エラー処理は後で付け加えるかも知れませんが、今はとりあえず動くモノを作ります。

　なんかいいアイデアやテクニック募集ちう。

　NScrはマニュアルが整備されてなくて分かりにくい！
　*defineの部分さえ書くのもめんどくさい！
　とゆー意見があるかどうかは分からないですが、JavaScriptを使って、NScrスクリプトの定義節「*define」の部分を簡単に作れるかも知れないモノを製作中。
　というか、ラジオボタンとかチェックボックスとかで値を放り込んでいくだけなんですが。
　仕様が面倒くさかったり処理実装が厄介だったりで、対応してない命令もありますが。
　当然のようにデフォルトでの使用に限られ、カスタマイズには全く対応していませんが。

　それでもまぁ、それなりのモノができたら、こっそり上げておきましょうか。

　慣れてる人だったら、こんな物使わずに、自分で書いちゃった方が早いんですけどねｗ
　需要はあんまりないだろなー。
　初心者向けだろうなぁ…これは。

　出来上がるまでに飽きちゃったら、またオクラ入りです。
　というか、今回と同じような物を数年前に作ろうとして、そのまま放置してた結果、当時書いてたソースは全て埋没行方不明。どこへ遣っちゃったもんだか。
　んなわけで再製作しているの物は、スクリプトもスタイルシートも埋め込んでいるので、お持ち帰りにも華麗に対応予定（笑）。

　えぇ、当面の娯楽ですとも。

　とりあえずテスト動作確認＆修正やってみました。
　今までやってたのが脳内デバグだけだったんで、ポコポコとエラーが出たりするんですが、まぁある程度は仕方ないもんだと考えてます。
　そんでも、さすがに
;-----------------------------
　...
　if %0==4 mov %0,2
　if %0==3 mov %0,1
　if %0==2 mov %0,4
　if %0==1 mov %0,3
　goto ...
;-----------------------------
　なんつーソース書いておいて、「思った通りに動かない〜」なんて吠えてる自分がアホらしくなってきたりするわけですが…。

　そんでも、一応動くようにはなりました。
　ただしパーツが出来上がっていないので、即席で代用パーツをノソノソと作ってあてがってみました（画像参照）。…って。
　これは平面２Ｄダンジョンじゃねーか（爆）。
　…いやまぁ、いいんですよ。要は「見せ方」なんですから。
　現状：イベントや戦闘抜きにして、配列変数マップを自由に移動できるようになりました。しかし初回の起動が遅い…。何もかもいっぺんに読み込んでいるので、当たり前といえば当たり前なのだけど。

　前回に引き続き、企画話です。
　戦闘ルーチン組むのに飽きたので、も一つのギミック、「パズル」を組むことにしました（ﾜﾛﾃ）。
　パズルつっても、やれそうなのはたかが知れてるんですよねっていうか、あまり思いつきません。単にネタの引き出しが少ないだけだな、こりゃ…。
　んなわけで、「ピクロス」を組むことにしました。
　勘のいい方は既にお気づきでしょうが、この企画（プロット）、大雑把に言えば「世界の果てで恋を歌う少女〜YU-NO〜」からイメージを頂いております。まぁ、どのへんが、と訊かれると困るんですが（笑）、詰まった時はあらかた参考にしています。
　つまり、似てくれば似てくるほど、詰まってた証拠…いやﾅﾝﾃﾞﾓ。

　で、ピクロスですが。
　パッと思いつくのは、スプライトボタンを使う方法です。この方法は確かに良さそうな気がしますが、ちょっと待てよ、と。
　ボタン化するっつーことは、「ＯｎＭｏｕｓｅ/ＯｕｔＭｏｕｓｅ」の二つのセルを持ってなきゃならない、ってことになります。加えてこの場合は、「ＢｕｔｔｏｎＯｎ/ＢｕｔｔｏｎＯｆｆ」の二つの状態をも実装しなければならんのです。つまり、鬼のようにspstrやexbtnを駆使して、スプライトの状態をこと細かに管理しなきゃならないってコトになります。
　だったら、ｓｐｂｔｎにしなくてもいいんじゃないの、と考えるわけです。
　それ以外に使えそうな命令といえば…そう、ｃｌｉｃｋｐｏｓを使う。これでいこうと決めました。

　１・ｂｔｎｗａｉｔのために「ＳＥＴ」または「ＯＫ」のスプライトボタン一個だけをセットする。
　２・画面上に方眼のスプライトを流し込む。12×12なら144個になる。
　３・ｂｔｎｗａｉｔの返り値を取る。返り値が0だった場合は「ボタン以外の所をクリックした」場合なので処理を移し、そこからさらにｃｌｉｃｋｐｏｓで絞り込んでいく。
　４・…というふうに。

　まぁもっとスマートなやり方はあるでしょうし、144個のスプライトにしたって、2×2の全パターンをセルに収めてしまえば、36個で済むんですけどね…。ちなみにその場合、セル数は2＾4＝16になります。このあたりが現実的でしょう。
　3×3で切った場合はスプライトは16個ですが、セル数は2＾9＝512。
　絶対にやらねって（笑）。

　ほとんど覚え書き的に（笑）。

　NScrで３Dダンジョンを作っております。
　前回…というか、かなり昔に作ったものは、番地ごとに一々四方の地形データを設定して、しかもそれをif＆gotoするという、とんでもなく構築しづらいものでした。おまけに、書いた本人にしかメンテナンスができないという（爆）。
　その点を踏まえ、また、NSｃｒ自体もバージョンが上がって実装命令機能が増えたということで、ばっさりと一新してみることにしたのでした。
　…というのが、数年前。
　この一年、考え事するヒマだけは大量に腐るほどあったので、ゆっくりと専念することができました…えぇ、じっくりと。

　まぁ、実装は至って簡単で、三次元配列をそのまま階層フロアに見立てて、関数っぽいものをモソモソっと通して、画面上のスプライトに反映させよう、というものです。
　そんだけなんですな。三日で書き終えた（ぉ）。

　ソースはすでに書いてるので、あとは４月に帰ったら、即動作チェックに入るだけですわ（笑）。
　つっても、ダンジョン解析の部分だけ出来てる状態なんであって、戦闘部分とか、あと、肝心のシナリオとかは、半分もできてない…。
　戦闘は普通の殴り合いでもいいけど、できれば簡略な、スッキリしたものにしたいなぁ。
　今のところ、カードバトルを考えてます。
　となると、ルールとかも自前で考えなきゃならんわけですが。
　もうしばらく時間もあるってことで、そちらを重点的にやってこうかと思ってます。

　やっぱ創作は楽しいねぇ。

　どんなプログラムでもそうだと思うが、というか間違いないのだが、設計というものは非常に重要である。
　言語によって差異はあるだろうが、概ねの動作モデルを書いて全体像を作り上げ、それらを小さな動作部品に細分化して、改めてボトムアップに組み上げていく、というのが普通のやり方だろうと思う。
　トップダウンとボトムアップ、両方からの視点に優れた設計だと、メンテナンスや拡張がわりあいと容易になる傾向がある。処理をきっちり把握して、全体像の中での位置付けを意識したビルドを行えば、そうそう珍妙なエラーが出ることはない。

　翻って、開発環境を見てみよう。
　NScrの場合だと、ローカル変数というものが存在しない。
　どこで使うにせよ、アクセスする変数はシステム全体に渡って有効であるということになる。
　つまり、「うっかりしてnull化しなかったわん」という変数があった場合、それが後々の処理に影響を及ぼすという事も、十分に考えられるのである。

　Ver2.48の現在では、「defsub」命令で、引数を取るサブルーチン処理が可能になっている。
　サブルーチンの中で使った変数は、他の処理へ渡す必要があるものを除いては、常にnull化（初期化）しておくクセをつけておいた方がよいだろう。
　文字変数は、「mov $0,""」等として、
　数値変数は、「mov %0,0」等とする。

　いつも心に「How am I.」、「自分、どないやねん」の心が大事。
　「それでえぇんか、えぇのんか？」と。

　NScr概論。
　個人的に見てきた多くの場合では、初心者ほど「全部ブッ続け」で書く傾向がある。これがある程度書き慣れてくると、処理ごとにブロック分けするようになるようだ。
　だから、他人のソースを読んでみて、「どこへ行くのよこの処理は」と思ったようなものは、概ね若葉マーク謹製だと考えてよい。

　基本的な考え方は、NScrに限った事ではないが、ゲーム（作ろうと思うもの）全体を、部品の集合として考える事にある。
　ノベル形式であれば、「タイトルメニュー」「シナリオ本体」「フローチャート」「周辺諸処理」がある。「フローチャート」は往々にして「シナリオ本体」に吸収されてしまいがちだが、小規模の作品ならともかく、シナリオが500KB（適当値）を超えた作品となると、それはメンテナンス性を下げる要因でしかなくなる。
　「その時動けばいい」ではなく、「忘れた頃に触っても改造できる」、それを念頭に設計していくのがベストだろうと思う。

　従って、各処理からのアウトプットは明確にしておき、それで足りないと思えば、関連するコメントを付けておく。
　これが案外重要なのだ。

　続きは次回。

　フリーのゲームエンジンである「NScr」のテクニックというか、思いついた事でも書いていこうかなー、と。
　読む人がいないだろうとか、興味ない人には面白くもないだろう、とかは一切考えない。
　むしろアイデアメモみたいなもんであり、また、一種のデザインパターンのようなもんでもある。
　読んでて分からない部分があっても、私は関知しません。あしからず。
　上記の「NScr」はフリーソフトでありながら、商業クラスの開発まで行えるという、ある意味、非常に強力なツール（開発道具）である。
　そのため利用者の裾野は広く、超上級者（何せ開発者本人が使っている）から、超初心者まで、あらゆる人が使っている。そこから生み出されるスクリプトも、また多種多様である。

　先日、某氏が書いたプロトタイプを見せてもらったところ、驚いた。
　700KBくらいのシナリオソースの中に、全てのスクリプト命令が埋め込まれていたのだ。
　もちろん、シナリオフローを抽出して別で管理、などしている筈もない。
　そしてその代わりというわけでもないだろうが、どう見たって不要なコメントアウトが山盛りになっていて、なおさらソースを読みにくいモノにしている。
　「あぁ、素晴らしい力作ですねぇ」と言っておいたが、できれば、あんなソースには関わりたくない。

　また別の某氏の話。
　「これでお願いしますねー」と渡されたソースは、特に必要と思われる箇所を除けば、殆どコメントもなく、最後に簡単なフローチャートが添えられていた。
　およそ100KBのシナリオソースだったが、ざっと読むだけで、設計にかかる事ができた。
　渡された材料から推察するに、この某氏の頭の中では、おそらくほぼ完全な動作イメージが出来上がっていたのだろうと思う。

　ダラダラと書いていくだけの人もいれば、綿密な設計を行ってそれから書き始める人もいる。
　どちらかといえば、後者に分があるようだ。