自慢になりますが「地下鉄でＧＯ！」の機能として画期的なのはＡＩがついていること！

今日から３回くらいに分けて自慢の停車ＡＩについて語っていきたいと思います！

0cm停車を自動でする（たまに外す）プログラムは以下の通りです

xxx=x-kohi/50:xxx=xxx/2110*xxx
paa=aa
if xxx/12>y:aa=-1
if xxx/19>y:aa=-2
if xxx/30>y:aa=-3
if xxx/40>y:aa=-4
if xxx/49>y:aa=-5
if xxx/57>y:aa=-6
if xxx/63>y:aa=-7
if xxx/72>y:aa=-8
if paa<aa:aa=paa+1
if paa>aa:aa=paa-1

ここで重要なのは緑色の部分。

緑色の部分では

変数ｙは残りの距離、ｘは速度が代入されている変数で

ｘｘｘは多少の補正がかかっているもののｘの２乗に比例する変数です。

aaはマスコンのブレーキ「Ｂ？」の？が代入されている変数です。

マイナスがついているのは加速減速を区別するための意味づけにすぎません。

気にしなくていいです。

（今更ですがこの電車はワンハンドル操作です、加速減速Ｐ５～Ｂ８までひとつの変数で管理してます）

さて、基礎知識としてここで速度と距離の関係の話をしましょう。

ある速度で移動している物体が一定の減速度で減速して止まったとき、それまでに進んだ距離は最初減速し始めるときの速度の２乗に比例する、っていう法則みたいなのがあります。

たとえば時速６０キロで走っている電車がブレーキをかけたら２００ｍ先で停車したとしましょう。

同じ強さのブレーキでは時速３０で減速した場合５０ｍ先で停車することが計算から分かります。

つまり話を戻すと、電車が走っているときのブレーキの強さを決定するＡＩはどうなっているのかというと、

ブレーキの強さが８パターンあるので、８回、各々の強さのブレーキで減速した場合どこに停車するかを

計算で出し、一番０ｍ（停車位置）に近いときのブレーキの強さを加速度の変数aaに代入する

というふうになっているのです。

計算で出すというのはつまりさっきの２乗の法則で計算すれば出るということです。

８回各々の強さで計算というのは、ちょうど緑のところですね。

このアルゴリズムでは、停車位置が０ｍをオーバーするものの中で一番近い停車位置の場合のブレーキを計算しています。

さて次は緑の行を１行１行解説していきます。

次回：技術解説「地下鉄でGO！」その７　0cm停車を器用にこなすＡＩ②

前回の記事はかなり適当すぎました・・・

もう３分で終わらそうと超高速でキーボードを叩きまくって書いたもので・・

そういえばいつの間にかメカマスター氏の鋼鉄親子でゲーム漬けのブログのアクセス数が２０万ヒットを超えていました

また記念にゲームの公開をするのかと思いきやまったく反応なしでしたね。

思いきやどころかそもそもそういうゲームの依頼ってすぐ俺のところに来るので、そういうことに関しては俺が一番分かってるはずなのに

あ！！・・そういえば、そんな依頼が確か３、４ヶ月くらい前に来てたわ

全然俺が手つけてなかったもんでお互いずっと忘れちゃってたけど。

まいっか

ところで、ＨＳＰコンテスト２００９の仮サイトがオープンしましたね！
今年は何人参加するのでしょうか！？

（そもそも自分は参加するのでしょうか・・・？）

さらにＨＳＰver3.2だかベータ版だかが公開されてて、早速ダウンロードしてみたのですがその中のサンプルで物理演算のプラグインを使ったプログラムがもの凄いのなんの！

多角形で何十個ものオブジェクトの力学的挙動が再現されていて尚且つスペックも食わない！

なにかフラッシュのゲームで物理演算のきいたゲームをＨＳＰで作りたいなーと思っていたのでこれを使わない手はないなとおもいますね！

このプラグインの登場で今後ＨＳＰコンテストで面白いゲームがさらに増える予感がします！

個人的には、多角形同士の当たり判定やそういう物理演算の処理も自分でアルゴリズムを考えて全部標準命令で作りたかったという思いもあるので、
先越されたなーって、ちょっとやられた感がありますが、まぁ物理演算は範囲が広いですから。

このプラグインでまだできない物理演算をちょっと標準命令で作って、いつか審査員を驚かせてみたいものですな

次回：技術解説「地下鉄でGO！」その６　0cm停車を器用にこなすＡＩ

気づいたら全然更新していませんでした・・・

でもわざわざブログ書く時間もないので今日は１行プログラムで、

カラーの画像をモノクロ化するプログラムです。

正直１行じゃ誰もわからないと思うので１行を見やすくして４０行くらいに展開してみました

dialog "*",16,"画像ファイル読み込み"
picload refstr,1

buffer 1,1280,480,0
buffer 2,640,480,0
color 0,0,0:boxf
mref a2,66
buffer 3,640,480,0
color 0,0,0:boxf
mref a3,66
buffer 4,640,480,0
color 0,0,0:boxf
mref a4,66

gsel 1
redraw 0
pos 0,0:gmode 0:gcopy 0,0,0,640,480
color 255,0,0
boxf 640,0,1280,648

gsel 2
redraw 0
gmode 7,640,480,256
pos 0,0:gcopy 1,0,0,640,480
gmode 3,640,480,170
color 0,0,0:grect 320,240,0,640,480
memcpy a4,a2,480*640*3-2,0,2

gsel 1
color 0,255,0
boxf 640,0,1280,480

gsel 2
color 0,0,0:boxf
gmode 7,640,480,256
pos 0,0:gcopy 1,0,0,640,480
gmode 3,640,480,170
grect 320,240,0,640,480
memcpy a3,a2,480*640*3-1,0,1

gsel 1
color 0,0,255
boxf 640,0,1280,480

gsel 2
color 0,0,0:boxf
gmode 7,640,480,256
pos 0,0:gcopy 1,0,0,640,480
gmode 3,640,480,170
grect 320,240,0,640,480

buffer 1,640,480,0
mref a4,66
color 0,0,0:boxf
gmode 5,640,480,256
pos 0,0:gcopy 2,0,0,640,480
pos 0,0:gcopy 3,0,0,640,480
pos 0,0:gcopy 4,0,0,640,480

gsel 2
color 0,0,0:boxf
memcpy a2,a4,480*640*3-1,1,0

gsel 3
color 0,0,0:boxf
memcpy a3,a4,480*640*3-2,2,0

gsel 0
redraw 0
color 0,0,0:boxf
gmode 5,640,480,256
pos 0,0:gcopy 2,0,0,640,480
pos 0,0:gcopy 3,0,0,640,480
pos 0,0:gcopy 1,0,0,640,480
redraw 1

buffer 4,4,4,0
buffer 3,4,4,0
buffer 2,4,4,0
buffer 1,4,4,0
sdim a2,1
sdim a3,1
sdim a4,1

１億桁×１億桁の開発は・・・ごめんなさい。なんかもう行き詰ってます（泣

だいたい１億桁×１億桁計算する前に１億桁を入力するだけでもすごい時間かかってしまうじゃないですか！！

だれもやりませんよそんなの・・・てなんで自分で自分を否定するか・・・

もう決めた。

これはあきらめよう！

うん。決断は早いほどいい。

せっかくだから作りかけの１００万桁×１００万桁のプログラムを応募しちゃえ！

いやーこれでも画期的ですよ！

本来なら２分３分かかってしまう計算がたった３秒足らずで！

と、いうわけなので、ＨＳＰコンテスト２００９応募作品１

その名も「１００万桁×１００万桁を計算するソフト」

うむ、我ながら良いネーミングセンスだ

でもこれじゃ誰もぎゃふんと言わせられないので、なにか別のプログラムを作らないと。

そうだな、特にショートプログラムで作りたいものだ。

そして去年のレイトレみたいに技術的にすごいのがいいなぁ

となるとやはり視覚的にうったえるもので、なにか派手なものは・・・

やっぱアルゴリズムにかかってくるに違いない。

例えば、ちっこい文字がたくさん飛んでて、どっかに吸い寄せられて形を作るものだったり、

幻想的な模様を再現したり、それこそレイトレみたいに光源の計算だったり、

全部アルゴリズムしだいでインパクトさが決まるような

よし、なにか次回までに考えてくるとするか。

今日の名言

「手で割ればすむものをわざわざ機械を使うなんてねぇ。ああいうものを買う人の気持ちが分かりませんよ。どうせ買うのは卵なんか割ったことの無い関白亭主ですよぉ」　ｂｙ　ノリスケ

今まで分かりやすくあえて遠近法といってましたが、正確には遠近法はただ遠くにあるものが小さく見えるだけ、

って定義らしいので、厳密な式にするのはできないそうです。

上の文は嘘です。

さて遠近法の式をつくりましょうか。

まず、近いほど大きく、遠いほど小さく見えるといいますが、どのくらいがわからなければいけません。

図に描いて見れば分かりますが、これは奥行き（ｚ座標）の距離に反比例して大きく見えます。

だから、画面の中心を320,240とすれば

例えば40,50,90という空間の点は、２Ｄ画面では

320+k*40/90　240+k*50/90　っていう点で表されます。（kは係数）

ここでkは大体500とか、そのくらいの数になるはずです。

では地下鉄でＧＯの柱のプログラムを公開しましょう。多分理解できるはずです。

（ちなみに左右にあるあの茶色っぽい細長いのが柱です・・・一応・・・）

color 3573450/q7.cnt+19,3573450/q7.cnt+19,3573450/q7.cnt+19
boxf 192+(8000000/q7.cnt),170-(5100000/q7.cnt),191+(7300000/q7.cnt),170+(5100000/q7.cnt)
boxf 188-(8000000/q7.cnt),170-(5100000/q7.cnt),188-(7300000/q7.cnt),170+(5100000/q7.cnt)

ほい。

カラー指定は、奥なほど濃くってことでしょう。

q7.cntは自分とその柱までの距離が代入された変数です。

cntはループのなかでしか意味をなさない、今何週ループ目？が代入されているシステム変数です。

柱はいくつもあるので、この３行の命令は２０回ループで読ませています。

画面の中心はなぜか190,170みたいですね。

そして　(8000000/q7.cnt)　ここの部分

割り算を使っているの分かりますか？

q7.cntは奥行きの距離でしたよね？

また、8000000や5100000とかものすごい数になっているのは、kに１０００倍されたx座標を掛けたからです。

精度のところで説明したように、全部の距離が１０００倍にされて計算されています。

小数も扱える変数だったらこんな事しないんですけどね

今日の名言はー

「びゃあ゛ぁ゛゛ぁうまひぃ゛ぃぃ゛ぃ゛（訳:ああ、うまい）」　ｂｙ　Ｍ・Ｈ