> 自由時間の会話の流れの例 ローカルルールが多すぎるので一概には言えないんですが、 「自分の職業は○○です。特殊能力を使った結果を発表します」 というような話が出たり(人狼側は偽情報を流したりしてかく乱させる)、 「～～という理由で、この人は怪しい（村人の振りをした人狼ではないか？ ）と思います」 というような感じ。 これをCPU が再現するのは非常に難しいわけで、元のゲームそのままの楽しみ方をするのは大変かもしれないですね。

>say さん DS のキラゲーム？ っていうのは知らないから、そっち方面では知らないけど…… 人狼ゲームは、参加者全員が推理(と騙し合い)をしながら進めるゲームなので、参加者にCPU を混ぜるなら、そのCPU はAI って事になりますね。

人狼の紛れこんでいる村にやってきた上で平然としてる猫とか、どうみても化け猫の類いです（ぇ 猫又か……

翌朝。村人は異変を感じていませんでした。しかし…… 再びの夜。人狼たちは、一人の村人を食い殺しました。 しかし、村人の中には、人狼に対抗できる能力を持つ人間もいたのです」 とここまで書いてから思ったんだけど、「汝は人狼なりや？」で検索したらネットで出てきます。 （書くのが面倒になった） このオープニング風のモノローグの続きは、（もし誰も人狼作らなかったら、来春にでも作成しようかな、と思っている）初版で公開されることでしょう。

えーと、もしかしたら世の中に「人狼」っていうゲームが複数あるかもしれないですが…… ここって他サイトのURL書いたらダメなんでしたっけ？ だとすると適当に説明するとして…… 自分が認識しているのは 「ある小さな集落を、数匹の人狼が狙っていました。 その人狼達は、人間に化ける能力を持っていました。 ある晩、人狼はついに村を襲う決意をしました。 まず最初に、一匹の人狼が一人の村人を食べて、その村人に化けました。 同様に、他の人狼も別の村人を食べて、その村人に化けました」 （続く）

おお、そうなのか。その情報は知らなかった。 コンピュータ将棋の次の段階にあるのかぁ……

それはいいけど（まさに言いだしっぺの法則）、今作ってるのと、大喜利用のとが終わってからだから、最低でも来年の春以降！ １番の仕様であれば、そんなに難しくないからキュウビさんが勉強して作った方が早いかもですよ？

世の中には言いだしっぺの法則、というのがありまして（ぇ でも、ちょっとこれは心惹かれるものがあるなぁ…… 本格的なのは人工知能の実装がとても大変だし、そもそもプレイヤーの完全自由発言を解釈するのは無理だから、そのまんまってわけにはいかないだろうけど…… １．役職配りと夜明けの結果発表だけ実装してのパズル系ゲームである初版 ２．通信機能を実装して、複数人で遊べるようにする続編 ３．CPU に個性付けをして、なんか色々それっぽくする最終版 とかそんな感じになるのかな？ 今忙しいから、とてもじゃないけど手をつけられないけど。

ん、GOSUB の方のプログラムはこれ、エラー出てないだけでミスってますね。 本当は、GOSUB @LOOP を最初の行に持っていって、そしてその次の行にEND が必要ですね。 それはそうと、DEF の方はDEF 命令内でローカル変数を定義すると再帰可能数が減りました。 DEF 用のメモリは、呼び出し位置の記憶と、ローカル変数用のメモリを共有しているっぽいですね そして…… えーと、GOSUB を10000回くらい再帰させてからDEF の再帰を呼び出すのと、16000回くらい再帰してからDEF の再帰を呼び出すと、DEF の再帰可能数が減ったので…… GOSUB と DEF って、メモリ共有してるんじゃないのかなぁ？

ちょっと興味があって試しに再帰処理のループ数をチェックしてみました。 DEF LOOP INC X:?X:LOOP END LOOP と、 @LOOP INC X:?X:GOSUB @LOOP RETURN GOSUB @LOOP です。結果は、DEF が2730、GOSUB が16383でした。DEF の値が中途半端なのが気になりますが……　GOSUB が圧勝なのは確か。 DEF の方は、ローカル変数の為に余計にメモリ食ってるのかなぁ。

GOSUB や DEF は、 「（RETURN なりEND なりに到着したら、元の場所に戻らないといけないから）どこから呼び出されたか」 を覚える必要があるのです。 そして覚える為にはメモリが必要ですが、当然そのメモリは無限にあるわけではないので、ある程度以上はメモリ不足になります。

さて、これで一応上下左右の移動は出来るようになりましたが、まだまだ移動処理としては不完全です。 その為、次回は衝突判定でも組み込もうかと思っていたのですが…… ちょっと実際にこの状態で動かしてみると、キャラクターが小さすぎる感じを受けます。 なので、次はキャラクターの移動はひとまずおいておいて、 次回：「２画面モード」 次々回：「フォントサイズの変更」 をやりたいと思います。 ※マップ画面とステータス表示画面が異なるのはいいにしても、マップ画面とメッセージ表示画面が異なるのはちょっとどうかなぁ、と思わないでもないですが…… でも、WIDTH 16 モードでの文字表示ってすごい読みづらいんですよね。

これは、 「"I"ボタンが10フレームの間押されていたら、その後は、5フレーム毎に連射する」 という意味になります。 十字キーは、上下左右4ボタンある扱いで、番号としては 0 ～ 3が割り振られています。 そのため、FOR ～ NEXT で合計4回、BREPEAT を設定しています。 この連射機能ですが、どうもBUTTON(1) でないと上手く機能しないようなので、21行目のBUTTON()命令で1を指定する事にしました。

※30行目と31行目のコードは、前回より修正が加えられています。 （30行目では NX を使用するようにしたのと、31行目では、X の値の更新をするようにしています） 次に、移動速度の問題ですが…… 解決方法は複数あるのですが、今回は、BREPEAT 命令を使いました。 この命令は、「ボタンの連射速度を指定する」命令です。 18行目でFOR ～ NEXT とともに使っていますが、繰り返し部分だけを見ると BREPEAT I,10,5 となります。

28行目では、新しい座標(NX,NY)と今の座標(X,Y)を比べて、位置に違いがあるか否かをチェックしています。 29行目～31行目では、位置に違いがある場合の処理をしています。 （今の座標にある文字を空白で上書きして、新しい座標にキャラクターを表示。その後で、今の座標(X,Y)の値を、新しい座標で上書きしています） このチェック（とキャラクター位置の更新作業）が終わったら、またボタンの入力チェック(21行目)に戻ります 以下繰り返す事で、キャラクターの移動を実現しています。

まず21行目で、何かボタンが押されているかどうかをチェックし、何かが押されているなら、押されたボタンを変数 B に確保します。 もし何も押されていないなら、Bには 0 が代入されます。 23行目～26行目で、変数 B の値をチェックします。#UP～#RIGHT は、上下左右に相当する数値の事で、この数値と B が一致するなら、該当する十字キーが押されている事になります。 十字キーが押されていれば、その方向に1マス進んだ位置にキャラクターを新しく配置するので、その座標を求めています。 ※新しいキャラクターの座標は、(NX,NY)になります。

（前回の続き） さて、前回はキャラクターを上方向に動かせるようにしました。 今日は、上下左右に動かせるようにするのと、移動が早すぎる問題を解消しました。 まず上下左右への移動ですが、これは上方向への移動の応用です。 方向キーの検知を21行目～26行目で行っています。 ※前回と異なり、21行目のBUTTON() の引数が1 になっていますが、これは後で説明します。

シンプルRPG製作日記 9日目 キャラクターを動かそう ～その2～

なお、これだけでは、上にしか移動できないので、これを上下左右すべてにおいて実装すれば、キャラクターの移動がとりあえず実行できます。 （上下左右ボタンは、それぞれ#UP, #DOWN, #LEFT, #RIGHT に相当します） 次回は、上下左右を実装して…… そして、移動速度の調整を行いたいと思います。 （今のままでは、1フレームに1マス移動するわけですが、これはRPGという事を考えると、ちょっと早すぎる移動速度なのです）

（ループ開始） １．今、押されているボタンを取得する ２．もしそれが「上ボタン」なら、キャラクターの移動先座標を、今の座標 -1 にする ３．もし、キャラクターの移動先座標が現在座標と異なっていれば、キャラクターを移動し、現在座標を更新する （１に戻る）