進行記2003

進んだようならカキコミカキコミ

 戻る


 ●2003年

1月12日

え〜と、明けましておめでとうございます。ってもう12日なんですが・・・
とりあえず今回は何も無いですがアイサツだけってのもなんなので
石板庭というパズルのアイデアができた経緯なんかを。

元々わたしゃパズルゲームが好きで、倉庫番とかテトリスとか色々なパズルをやってたんですよ。
で、ある時倉庫番で凄い面に合いまして。何が凄いって、ただ単にだだっ広いだけの面で
解き方がわかってるのに歩数オーバーでクリアできない。クリアするには歩数を短くするしかない
という、倉庫番としての方向性を何か間違っている面でした。
これが数歩以内とか数十歩以内が目標とかなら話はわかりますよ。
でもね、それ確か9999歩が限界だったの(笑)

それから「広いだけの面はカス」という考えが頭にこびりついてしまって
逆に「狭くて面白いパズルは出来ないだろうか?」と発想を転換させたんですよ。
そして倉庫番なんかの押すだけ系のパズルってどうして面が広くなるのか?と考えた結果
角を曲がる時に、回り込むための広い場所が必要なのが原因らしい、という結論に達したんです。
     
   
 
田の荷物が自在に角を曲がるには、こんなふうに場所を空けてやらないといけない。
ならば、もしこれで角が何の細工もなく、L字の形をした角のままでゲームが成り立つなら
狭くて面白いパズルができるはずだ。こう考えたんですね。
ところが実際アイデアを出すとなるとこれがまた大変で
大量のアイデアが出ては消え、出ては消えしたんですな。

いわく、壁に押しつけると荷物がぬるんと逃げる→左右両方空いていたらどっちに逃げるんだ?
荷物を引っ張ることができれば反対側に回り込んで引っ張れる→いちいち回り込むのは面倒
荷物といっしょに横移動できればどうだ?→自分が移動する為の場所が必要。L字角は曲がれない。

わたしは昔からパズルのアイデアを考える思考は、常に頭の中に常駐させてまして
ある日なんとなく考えながら部屋の引き戸をガラッっと開けた途端「これだ!」と思ったんですよ。
そう、スライドの動作です。説明にあった通り、あの動きは引き戸を開く動作から思いついたんです。

それから、そのルールに見合うようにクリア条件を設定したり面を作ったりして
石板庭が出来あがったんですな。ただその時、実はまだパソコンを持っていなくて
アイデアはあってもゲームが作れない状態でして、アイデアのまま何年も埋もれてました。

で、2002年の秋、ふとしたはずみにその資料が見つかって
面データーは残っていませんでしたがルールはわかっていたので
これはぜひとも世に出さねば、という思いからJAVAを学習して完成させました。

「ルールが少ない」「感覚的にルールがわかる」「面が広くない」「理詰めで解ける」「ひらめきも必要」
などなど、自分が考えている良作パズルの要素をほとんど盛り込めたので
石板庭は自分でもかなりのお気に入りです。ただ、あまりにも要素をシンプルにしすぎて
面を作るのが難しいという弊害もありますが。
まぁそれは自分が苦労すればいいだけの話なのでこれでいいでしょう。

とまぁこれが石板庭が産まれた経緯でした。
とりあえずゲームができちゃったので今年はあまり更新されないとは思いますが
石板庭をiアプリ化したい欲望もあるのでまたーり進めていくつもりです。
では今年もよろしくお願いします。

2月12日

ちょうど一ヶ月が経過しました。iモードの勉強をちょこまか進めてますです。
しかしこのiアプリってJAVAな癖に全然JAVAじゃないですね。
メモリがあまりにも小さいからオブジェクト思考をしてはいけない。
BASIC言語のように小メモリですませられる方法が必要な言語です。
ノリは昔のポケコンに近い部類があるのではないかと思います。

で、新作面ですが、色々交えて7面ばかし作ってみました。
これだけ作ると似たような解き味の面が増えてきて取捨選択が必要になってきます。
おかげで何面かボツにしてしまいました。

石板庭iアプリでの面は、JAVAのをほぼ流用しますが一部は改変するつもり。
あのね、チェックしてみたらホトンドの面が外壁省いて5×5マス内で済むんですわ。
自分でも驚きですよ、まさかこんなに狭くて十分だったなんて。
ということで面構成は25マスでやってみます。
倉庫番型パズルでは最小だよね?これって。

2月13日

うおっと、よく見直したら上書きで消えてた面があったよ(汗)
ということで8面目に追加。難易度はPOPです。

iモードのJAVAを勉強ですが、このおかげでもしかして自分の今までのプログラミング方法
バグが出やすいんじゃないか?となんとなくわかりかけてきました。

今のやり方はマウスやらキーやら、なにか入力があればそこの{}内で
直接処理を始めていってるというマルチタスクな構造でゲームを作ってます。
でもこれって入力次第じゃ誤動作しやすいやり方なんだよな。
瞬間的なパルスで入力が二回あった場合とかで誤動作してるような気がします。

大抵の処理をrun内でやっちゃっておいて、マウスやキーは入力を代入させるだけ。
複雑な処理をする場合にだけ、それを別クラスにして見やすくするという
シングルタスクなやりかたのほうがゲーム作成には合ってるのかも。
また一つ勉強になりました。

2月23日 進行度:i石板庭、面セレクト部分のみ完成。

どうにかここまでできたよ。なんでかしらないけど、しばらく忙しくて放ってたら
環境がおかしくなったのかDOJAが起動できなくなってて、あれこれ試して
JAVA1.31からインストールし直しでやっと復帰。
う〜〜〜これやるだけで半日つぶれた。くそぅ。

でもまぁ、一度立ち上げることができりゃ後は楽だな、たぶん。・・・・・たぶんね(汗)

なんにしても、キー部分だけでもお約束が違うから戸惑ったよ。
最初作ったのなんかキーを押して放した後も数字がどんどん増えてくの。
で、改良しても押しっぱなしで増えてくから狙った位置で止めにくいし。
押した瞬間だけ1増やす仕様にするだけで時間かかったりして。

でも今回、ソース公開はできません。なぜって本に載ってたソースをほとんどコピペしたから(笑)
付属CDに入ってたソースのあっちこっちから、カット&ペーストの繰り返しっすよ。
独自の部分もあるけど、ほとんどそれだったから載せられねぇっす。著作権というより恥で(笑)

3月08日 進行度:i石板庭、完成。

 無事に完成しますた。このページの一番左上からどうぞ。
良く考えると途中経過、ここで全然書いてなかったな。
過去文見ると23日からだから、2週間で完成できたってことか。
夢中になると突っ走るタイプだから、とりかかれば速いんだよな、俺って。
そのぶん、他でやってるHPが全然更新されなくなる訳だが(笑)

思えば10月にページ立ち上げて約半年でここまできちゃったんだよな・・・
なんか、完成してみるといきなりやる事が無くなったって感じで気が抜けてます。
超大作RPGを一本やった時よりも深い充実感がまた〜りと体を支配してます。

アプリゲットにも登録したし(掲載はまだ)
しばらくはお遊びモードで他人の作ったゲームで遊んでみようと思います。
ではでは。

3月23日 即興iアプリ ゲームモナッチ(ナゲステロ)を作ってみる。

入り口はこのページ一番左上から〜。
作ってみたはいいのだがどうにも遅い。速くならなくて簡単すぎる。
ここがiアプリの限界かなぁ。それに思ってたより面白くならない。
う〜んなんでだろ?

あと、120×120じゃドット絵が厳しいっすよ。
どうにか詰め込んだけどなんかやっぱり荒くて汚いです。
俺はドット絵師にはなれねぇなぁ。

ボツにするのもなんなので公開だけはしときます。

4月4日 素人にお勧めできないJAVAアプレット

えっと、新しいパソの導入でXPにしてみました。速くて快適♪
インストールなどで色々てこずってます。そして色々な不具合も発見。

いやね、XPだとどうだろうと思って石板庭をやってみたんですよ。
そしたらジエンの動きがむちゃくちゃ速いんでやんの。
でも何かの拍子に遅くなる時があったりとかイマイチ不安定でね〜
正直JAVAって環境に動作が影響されすぎだと思う・・・

 だって、普通は速度とか変化したりしないじゃん。バージョンが上がったら
 ブロック崩しで動きが引っかかるとか困るじゃん。マシンが遅い時にはあれだけ
 楽勝だったシューティングが、速いマシンに変えた途端即死だとか困るっしょ。

 だから他の言語とかはあまりゲームスピードへの影響がない。話のわかるやつだ。
 だけどJAVAは違う。マシンスピードをマシンスピードのまま扱ってる。凄くヤバイ。

これだけ勉強したところでなんだけど、JAVAってゲーム作成には向いてないと思ったよ。
思えばJAVAのゲームでこれは凄いって思えるのって案外無いんだよなぁ。
一番流行ってるのはブロック崩しで、それでも表現は他の言語に比べると劣る。

しかもプログラムが作りやすいというわけでもない。動作が遅いからマシンスピードに影響される。
色々な細かい決まりごとがあって、それを知っておかないとまともに動かない。
マルチタスクは使えるけど、マルチタスクを使うと誤動作が多い・・・

同じミニゲームならFLASHのほうが表現豊かだし作りやすいし、スピード影響が少ない。
もっと高度なゲームならJAVAより利点の多い言語がある。
結局一番JAVAで一番利点があるのは、iアプリ開発なんだよなぁ・・・

そろそろ私もこのページも転換期を迎えたようです。
次の言語は何が良いか色々模索していこうと思います。

4月13日 自分なりに言語の優劣をまとめる

とりあえずいくつかそれっぽいのを。

FLASH (簡単なゲーム向け)
 利:IEで見られるならOK。回転拡大縮小の技が得意。画面の大きさも可変。
 不:コマンドがかなり少ない。2次元配列すら無し。セーブ不可。

JAVAアプレット (簡単なゲーム向け)
 利:IEが見られる環境なら大抵表示が可能。ツールが無料。
 不:約束事が多い。速度が遅い。セーブ不可。

HSP (ある程度複雑なゲームも可能)
 利:完成までが簡単。実行形式にできる。ツールが無料。オンラインも可。
 不:資料が少ない。本はほとんど無し。

VB (ある程度複雑なゲームも可能)
 利:完成までが簡単。実行形式にできる。
 不:実行側はランタイムを別に用意しないといけない。複雑なのは無理。

VC++ (複雑なゲームも可能)
 利:実行形式。資料が多い。開発環境が整っている。
 不:ゲーム作成には複雑すぎる。ツールが高価。

Delphi (複雑なゲームも可能)
 利:実行形式。ツール無料。言語体系が整っている。ツールが無料。
 不:資料がやや少なめ。ゲームでなく、データベースのための言語。


こうしてみると、ピコゲーなんかはFLASHが良さそうな気がする。
ある程度の簡単なものならHSPだろう。複雑なものになるとDelphiかな?
VC++は有料なのと、言語体系に難があるのをネットで聞いてるからちと敬遠。

今はもうJAVAを覚えちゃったからFLASHはいいや。
これからやるとしたらHSPかなー?
でも一足飛びにDelphiに行ってもいいかもしれないし。
もうちょっと悩んでみます。

4月17日 基本に戻って考える

HSPにしようかそれともDelか、まてまてFLASHもやりたいぞ
色々と考えているうちに迷路に迷い込む。迷路は好きだけど。

で、基本に立ち返ってみて気がつく。
俺は、言語を覚えたいんじゃないんだ。ゲームを作りたいんだ。
だからどの言語を覚えたいか?ではなく、どんなゲームを作りたいか?
という視点から言語を決めたほうがいいんじゃないか?ということに。
で、今作りたいゲームは何かというと・・・

●2chキャラのミニゲーム。これはFLASHあたりが妥当な感じ。
しかしJAVAがあるのに今さら新しい言語を覚えるのモナー。
とはいえ2chでは製作ものはJAVAよりFLASHが通常だから
いっそのことFLASHに移ってもいいかもしれないし。

●iアプリでちょっとしたアクション。今までの継続ですむから開始は楽。
ただ、遊んでくれる人が少ないというか、感想がまったく無いのがなー。
iアプリはちょっとした暇つぶしにいいから自分が遊ぶためのものと割り切って
しまうのもいいかもしれん。が、周りの反応がないとやはりやる気が萎える。

●JAVAアプリでスカッシュ。今、JAVAゲーで一番数が多いのがブロック崩し。
爆○健さんとこのやつね。それをスカッシュに改造してみたい。
バーとボールと絵を流用できるものにすればメインを置き換えるだけで
ブロック崩しから切り替えられる。ただ、こういうのって白い目で見られるかも。

●実行型言語で石板庭のリメイク。音つけて動作よくして色々飾ってみてみたい。
作るならHSPが妥当だろうな。でも将来性のことを考えると一足飛びに
Delを目指したほうが良いかもしれないし。作るのが簡単なことを考えると
HSPを覚えるのもいいかもしれない。

●通信対戦でカードゲーム。HSPならオンライン用のコマンドもあるからな
でもアイデアはあるけどその後のメンテがめんどいからCPU対戦のみでいいかも。

●カード&ボードの本格的オンライン対戦ゲーム。
たぶんこれが最終目標になるであろうという作成の複雑さと難易度。
HSPがどれほどの能力を持っているのかわからないので
これはHSPかDelかどっちで作ればいいのか難しい。
ゲーム内容は遊戯王+ダンジョンダイス+カルドセプトみたいな感じ。
一人じゃたぶん完成は無理だろうなぁ。

能力と時間で考えると、複雑なゲームはやはり難しいよなぁ。
となると、やはしお気楽に作れるHSPか?ってところ。
ただ、それぞれの言語でまだ作りたいものもあるから
結局は複数覚えるのがいいことになるな。かなり手間だけどね。

となると・・・
1:とりあえず今覚えている言語で作りたいものをあらかた作ってしまう。
2:次に簡単なFLASHでミニゲーム。これはあきらめて次に行くのもOK。
3:HSPで石板庭。カードゲームはCPUが難しそうなので後回し。
4:カード&ボードを頑張ってみる。3でHSPの能力を見極めて言語を決める。

こんな具合かね?やぁなかなか忙しそうですな。
いっそ会社辞めて一年ぐらい引きこもって製作に集中したいよなぁ(笑)

4月30日 サンプルゲーム S-CASH

だ、だめだ。JAVAってほんと遅すぎる・・・
弾き返しで弾速を変えられるブロック崩しもどきを作ってみたんだが
どうにもこうにも動きが遅くて困る。これ以上弾を速くすると
ブロックとの衝突判定が変になっておかしな動作するし。

おかげで作ってる途中で萎えてしまい、完成に至りませんでした。
せめてなー、1ドット単位で動いても遅さを感じないぐらいならなー。

@アプリだって今度は次の世代のDOJA3.0になっても
まだ機種ごとの速度差が解消されてないし・・・
いや、それより問題はパケ代なんだ。石板庭でわかったけど
作った奴を試すためにダウンロードするのって、意外とパケ代が
かかるんだよ。シミュレーターでやればいいんだろうけど
やっぱり実機との遅さが違うからどうしても確認したいし。
なんで赤外線とか有線ツールで転送できないんだろ?
くそっ、ボッタクリドコモめ。

なんか、そろそろJAVAに見切りをつけたほうがいいかなー
と思い始めてます。まだ休みはあるから違う言語でも
試してみようか?そうなるとそろそろここのタイトルも
変更しないといかんなー。

5月01日 色々考え直してみる

ただいま〜。立ち読みで色々調べて来たよ。
で、判ったこと。どうやら他の言語も弾を高速で移動させる時は
1ドットずつ動かしてはいないらしい。数ドット単位で移動させている。
で、何でだろう?と考えてみた。何がある?何か限界があるのか?

最初はフレームレートから来る限界か?とも考えたが
それだと30フレームだとしたら秒間30ドットしか動けないはずだ。
でも実験してみると秒間100ドット近く移動するし。(約95ドット)
ちなみにそのプログラム、スレッドスリープが0.01秒入っているから
ほとんど支障なしに1割る0.01秒で100ドット近くだから計算的にも正しい。
(普通フレームレートは秒間30(60)だから
 それ以上細かく移動させても意味無いんだけどね。)

でもなースレッドスリープ短くすると遅いパソの時に支障がでるんだよなー。
最近パソコン新しく組んだんだけど、石板庭の動きが前と断然違っててねー。
(ちなみに石板庭のスリープはたった4。2.4Ghzだと速い速い・・・)

あ、ってことは他の言語でも数ドット単位で動かしてるのは
遅いパソコンでも対応できるようにかな?
ん〜このへんはもうちょっと折り合いをつけて頑張ってみるかな?
どっちにしろ、これだけ速度差の出る言語はゲーム環境として良くないから
これからJAVAでのゲーム製作はあまりしなくなるだろうけど。

弾の跳ね返しと当たり判定は資料を読んでた時に厳密判定の方法を
色々学んだんで、それにチャレンジしてみます。

5月01日 S-CASH改良

ゲーム改良しますた。今回はかなりボールの動きが良くなってきました。
新しい方法を思いついたおかげで、なんか一皮向けた感じでつ。

あのね、処理と表示は別に1対1でなくてもいいってことに気がついたの。
一回の処理で一回の表示だと、複数ドット移動の時にどうしても
無理が出てくるんだよね。で、どうしたかっていうと。

1:ボールの位置情報を1ドット単位とせず、1/100ドット単位にする。
 具体的には横幅480ドットを内部数値48000とし、表示の時には100で割る。

2:移動値も1ドットでなく1/100ドットとする。例えば移動値29なら
 29を足していって100の位に繰り上がった時に初めて1ドット動く。
 (細かい調整が可能。角度とか)

3:もちろんこのままでは速度が遅いので一回の移動で
 一回表示でなく、10〜20回処理を繰り返してから表示させる。

4:このおかげで1表示の間に複数ブロックを突き抜けたり
 壁とブロックで複数反射が起こった時も、分割して一つずつ
 内部処理していくので処理抜け、処理落ちなどがなくなる。

たぶん前からある方法だとは思うけど自分的には目から鱗でした。
一気に処理できる方法を考えててどうしても駄目だったから
発想を転換させてみたのが、これほどうまくいくとは。
遅いと文句を言う前に、進んで処理方法を学びましょう。ですな。

こうなったらもうちょっとデコレートして完成させちゃいますかね。

5月02日 S-CASH完成

もっと手間をかければ配布できる程度のものにはなるだろうけど
プログラムの練習用だし、配布するつもりもないのでこれで完成とします。
配布するのは元ネタの爆裂健さんとこに失礼な気がするし。
っていうか練習で組んだにしてはあまりにもゲームが似すぎ(w

というわけでJAVAゲーム開発はこれにて一旦終了。
次にJAVAをやるとしたら、また何かやりたくなった時にでも。
で、今度はDelに挑戦してみようかと。いやね、HSPの資料をね、
でっかい本屋で探してみたんだけどさ、一冊も見つからないんだ、これがまた。
さすがにこれだけ資料が少ないのは敬遠したいなぁ、ということでDelphiに決定。

5月16日 気になる開発ツールが・・・

Delで行こうと決めた矢先にN88BASICで開発できるツールを見つけてしまう。
むぅぅ・・・こういうのもいいなぁ。正直かなり迷ってる。両方取得すべきか?
得意分野は多分違ってくるだろうし。過去の資産も豊富だろうしBASICなので簡単そうだし。
とりあえずHSPという選択肢はなくなったと考えて良さそうだ。

で、話は以前の進行記に戻ってブロック崩しのことで。いや、すごいね。奥が深いよ。
普通にボールを動かすだけなら単なる条件分岐でできるけど
厳密に当たり判定をどうこうやるとなると、かなりの技術がいるね。

一番問題なのは角の当たり判定。ボールがブロックの角に当たった時の反射角は
物理計算で考えるとかなり変化する。でもそんなことをするとゲームにならないから
ある程度妥協しないといけないんだよな。その妥協点をどうするかなんだよ。
あと、当たり判定を点にすれば計算が楽になると思ってたら、実はボール進行方向
上下左右どれか2点で判定したほうが反射方向の判定が楽だったりとか。
その場合でも角をかすった時に当たり判定が無視される問題があるとか。
あと、スピードの変化もあるし、考えれば考えるほど奥が深いよ。

こうなりゃ厳密ブロック崩しとか作ってみようかな?
となるとブロックも四角じゃなくて八角形とか三角形とか色々な形にして
反射角がさらに散らばったりとか。うわ、すごく計算が大変そう。

5月26日 5段重ね将軍

上のタイトル、メダルコーナーで見かけたゲームだが
パズルゲームとしてはなかなかいい線行ってると思った。

ルールは5箇所の空き地に1〜25の数字を積んでいくってもの。
ただし数字の上に置くのはもっと大きい数字でないといけない。
積む数字は一つずつ出てくる。ただし順番はランダム。
全部積み終わったらクリア。

          NEXT
  21        19
  20   09  
03 11   05  
01   07   14   02   10  

画面はこんな感じかな?
あと、出てきた数字とまだの数字が上のほうに表示されてたか?
数字出現は完全ランダムだといきなり25が出てきて詰みになるから
ある程度工夫が必要だな。1〜25を順番に場所ランダムで積んでいって
マスが埋まったらランダムに上から抜いたのを配列にすれば解法は
確実に存在するってことになる。

ゲームとしての難易度調整が難しそうだけど作るのは簡単そうなので
Delで作ってみようかと思います。

あ、そうそう。そろそろタイトルも変更しようかと。
Delに移ったのにいつまでも「JAVAったり」じゃ変だし。
今、違うとこでやってるホームページがほぼ完全に停止してるので
そちらをつぶしてこっちと融合してみようかと思ってます。

5月29日 勉強進行中

ちと難しいというか、JAVAとはまた違った形式なので
ツールの使い方を覚えるだけでも一苦労。
今日やっとプロジェクトの意味がわかったとこだったりして。
まだまだほんの入り口の周りをうろうろしてるだけの状態です。

とりあえずお約束の「Hello world!」表示はできました(笑)

6月1日 勉強難航中

BMPイメージを取得して表示させるだけなのにやり方がわからない。
で、さっきやっとわかったとこ。でもまだ色々なことが不明。
いきなりゲーム作ろうとしても細かい部分がわかってないと駄目だなー。
とりあえず、新しい言語でゲームを作るには何を覚えないといけないかチェック。

操作入力 内部処理 入出力
こんなところかな?この基本を覚えさえすれば後は組み合わせの応用だ。
Delでのゲーム製作をネットで解説してる場所を色々探したけど
どれもいまいちわかりにくくて難儀してます。もうちょっと頑張ろう。

6月18日 基本から考えてみる

あのね、JAVA勉強がすんなりいった後だからDELも1から
学習するのなんて簡単だと思ってのね。駄目だったよ。
やっぱりコツコツやらんといかんわ。

そういうことでJAVAのプログラムサンプルを無くして
Delphi学習ページを立ち上げることにしたよ。
まだ内容の無い空ページだけどこれから充実させる予定。
ゲームができるのはまだまだ先になりそうです。

6月24日 俺DEL 基本手順のページを作成

とりあえずの立ち上げから実行までの手順を明確に。
改めて発見するものも多くて、まさに俺DEL。

いやね、探してみたけど意外とぜんぜん無いのよ。
こういう基礎の基礎から理解させてくって解説ページが。

ハローワールドの仮実行を解説してそのまま次に行ったりするのが
解説本とかでもほとんどでさ。なんたって俺自身も実行形式に
する方法がわかんなくて悩んだもんだから。

解説も傍目には多少わかりにくい部分があるだろうけど
このままいっちゃいます。なんたって俺DELだから(笑)

7月2日 俺DEL プログラムの全体構成ページを作成

自分でもよくわかってなかったプログラムの全体構成を
なんとか説明しました。本当に合ってるかどうかは不明(笑)
DELのヘルプ見たら、専門用語ばっかりで
よけいに訳わかんなくなるしで大変だったよ。

自分にとって理解したかどうかの基準は
他人に説明できるかどうか?なので
一見、他人のための解説でも結局は自分のためなんだよな。

しかし最近時間が無くなってきてるからゲーム完成までには
まだまだ遠い道のりです。気長にお待ちくだされ。

7月14日 俺DEL procedure説明ページを作成

ゆっくりゆっくりですな。ゲームができるのはいつの日やら・・・
いやね、仕事が忙しくてどうにもこうにも。
仕事の現状体制が10月末まで続きそうなので
このペースも10月まで続きます。

7月20日 imode石板庭 裏モード公開

表を全部クリアするとURLが表示されていた裏ページを一般公開。
でも表がクリアできなきゃ到底無理な難易度ですな。
面はJAVA版のBITTERとDEEPから。ほとんど共通。
あと、0の長押しで面クリ情報がリセットできるのを書き忘れてたので追加。
某紹介スレの住人にサンクス。遊んでくれてありがとうです。

8月1日 ゲーム速度一定化について考えてみる

最近、ゲームスピードを一定化する方法について考えてました。
基準になると思ってたのはフレームレートで、これは画面の垂直帰還同期なんだけど
(詳しいことはgoogleでググってくれ)

テレビだと30FPSを二回に分けて60FPSにしてる。
でもパソコンの場合はそれが一定とは限らないんだよね。
ちなみに今、自分のだと1024×768の85.2Hz。つまりFPSは85.2になる。
ディスプレイが違うと当然FPSが変わってくる。
・・・んー、なんかFPSと垂直帰還同期とフレームレートとHzがごっちゃになってるな。
まぁ、俺も良く知らなくて使い分けてないから詳しいことは以下同文でググってね。

話を戻そう。環境によって画面を1秒に何回書き換えるかが違うんだから
もし、プログラムがそれを基準にしたなら、画面モードを変えただけで
ゲームの速さが変わってしまうはずだ。それはおかしい。
つまり、ゲームスピードの一定化と、画面の書き換え回数は関係ないと見ていいな。
(ディスプレイのカタログを見ると、だいたい50Hz〜160Hzぐらいの範囲)

で、結局なにを基準にすればいいのか?というと『自分で決めればいい』という結論に。
人間の目は秒間50〜60回以上の点滅は知覚できないそうで
それをだいたいの基準にすればいいらしい。まぁ書き換え回数は多いほうが
滑らかに見えるのは確実なんだけど100回もやるのは意味が無いよな。
あんまり回数多いとスペックが低いマシンでついてこれなくなるし。

ということで秒速50回を例にプログラムでの一定化を考えてみると。

                                 終了時刻
原点時刻                          原点時刻+0.02秒
   |→→→→→→→→→→→|→→→→→→→→→→|→→→→→→
     計算中        計算終  この間待機    終

こんな風に原点時刻を設定して、終了時刻までループで待機していればOK。
終わったら、原点時刻+0.02秒を新たな原点時刻にしてやれば問題なし。

もし+0.02秒までに計算が終わらなければ、さらに+0.02秒後。
この場合は計算が遅れると、ゲームスピードは半分になりますな。

半分にしたくなければ、原点時刻は終了した時点での時刻を使えば問題なし。
ただ、CPU負荷が高いからせめて一回は待機したほうがいいですね。

やー教わるのと違って自分で考えて突き詰めていくのって、ほんと楽しいや。
ただ、ゲームがまったく完成しないのが難点なんだけどね。それじゃまた。

8月8日 俺DEL 変数形式追加

1日の続き。ディスプレイの場合はかなり速い回数まで可能だけど
ノートなどの液晶だと実はこれがぐっと遅くなってたりする。
真っ黒→真っ白までの変化、これが実は最新の液晶でも0.025秒かかるんですね。
一見速いように思えるけど、回数にして秒間40回。かなり低いです。
実際には、中間色から中間色への切り替えが多いので
もっと速いとは思いますが、古い機種もあることを考えると
かなりのばらつきがあると思います。それにゲームというジャンルは
映像よりも画面変化が急なのでかなり厳しいでしょうなー

ということで現在やっと夏休みだったりする。
しかし家の手伝いやら急な葬式やらで手が空かない。ぐぅ。
まぁのんびりいきますよ。あせらずにね。

8月15日 俺DEL +−×÷の演算追加

悩んでいる。俺DELのページの一番下にジョイスティックの入力
と書いてあるが、実際それを調べると、どうにも方法が見あたらない。
ダイレクトXを利用して、の方法ならあるようだが
DELPHIそのもので使用する方法がどうにも見つからない。

う〜ん、そんなに難しいものなんだろうか・・・
確かにジョイスティックの種類っていっぱいあるし
中にはアナログやらの入力もあるからそれぞれに対応するのは
大変なんだろうけど、それでもDLLの一つも無いってのが・・・

一番実装したい部分が実装できない。う〜む、困った。
やはりダイレクトXが必須なのだろうか。

8月22日 俺DEL 画面に配置する部品。コンポーネント。

ジョイスティックの入力、2chで聞いて大まかなところを理解。感謝。
どうやらWIN32APIとかいうものを使えばいいらしい。
で、これはなにをするものかというと、ウインドウズを直接動かしてる命令群らしいんだな。
入出力やら、ファイル選択やら窓を開くのやらを制御しているもの。
完全に理解するにはまだ時間がかかるので、のせるのはだいぶ後になりまする。

それにしてもはじめてから二ヶ月。DELPHIの知識をまとめてばかりで
実際のゲーム作成がまったく進んでないってのがアレですな〜。
ま、基礎を固めるためにじっくり行くつもりですんで。

8月27日 俺のためのグラフィック学習

絵の表示、特にちらつき関係の説明について考えていたが
どうもこれだけでまるまる一個解説が必要だと考えた。
で、新たに作ったのが上のやつ。これは、この時点で出来上がってるので
新たに追加したりとかは無いです。
解説を判りやすくするための改善ならありえますけどね。なんか絵がいまいちだし(汗)

ついでにフレームレートの時間管理について調べたら
あれがいい、これがダメ、こういうやりかたならOK、なんかの
細かいテクニックによる時間操作がもう出るわ出るわ。

0.016秒毎を正確に、しかもCPUに負荷をかけずに行うには
かなりのテクニックがいることがわかりました。
これについてもまた後ほどで。

ほんと、ゲーム作成って奥が深いです。

8月31日 俺DEL 部品の設定。オブジェクトインスペクタ。

これで一番上の項目、作業手順はみんな埋まりました。
でもゲームのほうはまだまだ。なんていうか、ホームページを作るほうが
メインになっちゃってる気がします(苦笑)

なんていうか、もうちょっと実践的なもののほうが良くないかな?
すべてのゲームに使える基本の基本。骨の部分を作ってしまって
それでもって後は学ぶ側に任せる。みたいな感じで。

具体的に言うと それぞれなにを学習するかは略しますが、だいたいこんな感じ。
あとはそれぞれのゲームに必要な部分を追加していけば良いだけ。
俺Delのゲーム応用編とでもしますかね?

9月15日 俺DEL 判定、分岐、周回

ほんとにじわじわとだけ進んでます。時間無いのが辛いです。
秋は地元の行事やらナニやらで忙しいですし、会社も多忙な状態のまま。
う〜ん、こりゃゲームできるのが来年になっちまうな。

そろそろ実践スレ、じゃなかった俺DELゲーム応用編を作りながら
実際にゲームを作る方法で進めますかね。

10月19日 今回は何も無し。予定宣言だけ

気がつくと一ヶ月更新してない。やばい、宇宙やばい。
とりあえず秋の多忙行事は過ぎますたんで、更新は速くなりまつ。

で、実践スレの内容をどうするか考え中。
最初から5段重ね将軍で行こうか、それとも完全サンプルで15パズルに行こうか?

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

1:背景とキャラを重ねた絵を表示するだけ。動作無し。操作無し。

2:背景と重ねたキャラを動かす。ただしアニメーション無し。操作無し。

3:キャラを動かす。同じくアニメーション無し。今度はキーで操作できるように。壁判定つきで。

まずはこの3段階ですな。まずはゲームの根源、基礎の基礎。
表示と操作をしっかりさせて後は流れ次第で、ってな感じで行こうと思います。

ps.石板庭解説ページから戻るを押すと過去のサンプルに行ってしまう(汗)
でも面白いから隠し面としてそのまま残しておこう(笑)

10月21日 俺Del実践編スタート。止め絵の表示とキャラの横移動

まずは基礎の基礎から。基礎は大切。
実行形式を含めて作ったプログラムを
ダウンロードできるようにしてあります。

今回、一気に二段階更新です。
いきなり実践編なので、上の俺DELで解説してない部分まで
やっちゃってます。画像表示と時間管理のページを作らんとなー。

10月24日
名前変更。「実践編」から「ゲーム応用編」へ。
俺DELに時間操作、キーボード取得を追加。

ゲーム作成中心でやってるのに「実践編」じゃなんかおかしいんで
名前を「ゲーム応用編」へと変更しました。

10月26日 俺Delに関数ページを追加、ほか微修正

なんか基本的なことを忘れてないか?という思いが
だんだん大きくなってきている秋の夜長。
ゲームプログラム全体の構造がまだ解説してないなーと思う。

今、説明しようとして書いてみたら、見事にわかりづらいものが
出来上がったのですぐ消した(笑)

初めに使用するための変数やイメージを用意してからメインループを起動。
メインループでは、まずゲームスピードのための時間待ち。
(秒間数十回のループ回数を一定にさせないとゲームスピードが乱れるから。)
実行していい時間が来たら続いてモードごとに処理を分岐。
タイトルモードならタイトル処理へ
ゲーム中ならゲーム中処理へ。
ゲームオーバーならその処理へ。

で、分けたそれぞれの先でそれぞれを処理して
終わったらループの頭の時間待ちへ。

これをもっと見やすく書きたいんだが、どうもごちゃごちゃして・・・
そのうちに本当にこのやり方でいいのだろうか?という疑問が。
なにせBASICからあまりやりかたを変えてないから今のシステムに
似合う方法なのかが疑問でねぇ。

こういう全体的なプログラミング設計を勉強したことないからなぁ。

まぁ解説したとしても自己流なのであんまりあてにはできないページに
なりそうですが、足がかりとして参考になる程度のものを作っておきます。

10月27日 俺Delにジョイスティックを追加。応用編で操作できるページを追加

一気に進みました。ので、これでちょっと休憩。
ま、ここまで基本が判れば後は自然に進めるでしょう。

そろそろ前に書いてた5段重ね将軍、スタートしてみようかな?
ふと思ったんだが、これ、上にある数字が小さいほうが
感覚的に判りやすくていいんじゃないかな?
あと、5×5段だとちょっと大きいような気がするから
まずは4×4段ぐらいで作ってみたほうがいいかも。

プログラムに慣れたら縦横がフリーなものも作ってみたいです
縦横20段なんてアフォなこともできたりして。ぜってークリア無理(笑)

まぁ色々修正して、自分の味がでるようなものにしてみるつもり。

10月30日 悩んでいる

むむぅ、5段重ね将軍を4段にして、名前を「難パイル」と名づけたまではいいが
ループの無いプログラムに戸惑っている。

なんせ、表示がちゃんと反映される方法を探すだけでもここ数日を費やしてるし
反映されても、描き変えの時になんか一瞬ちらつくし。
いっそタイマーでのループ方式にしようかとも思ったりして。
でもそうなると、今度はボタンを押したときの処理がややこしくなるだろうし。
なんで素直に、ボタン→処理→表示ができないんだろうなぁ・・・

11月01日 ちらつきが解決したのでゲーム応用編を進める

色々解決しました。Form1.DoubleBuffered := True;これだけでいいみたい。
いやホントはもっといい方法、色々あるみたいなんだけどね。
一番簡単でほとんどちらつかないこれで十分。
WM_ERASEBKGNDを使うのがいいらしいとか、Bitbltを使う方法もあるらしいけど
どっちもウィンドウズを直接見る命令らしい。

ジョイスティックの場合は見なきゃ始まらないからそうしたけど
今回はそこまでする必要がない気がするんで「今は」スルー。
必要と感じた時に学習フラグ立てればいいよな。

11月02日 俺DELゲ応。難パイル、ゲームとして遊べるようになりました

一応遊べるようにはなった。が、まだなにかゲームとして物足りない感じ。
横に空いた部分があるからタイムアタックでもするか?
でもランダムの具合で激しく難易度が変わるしな。
大きさを変えて色々なサイズを遊べるようにする?
イメージやプログラムを1から作り直さなきゃいけないからかなり荷が重い。
積む順番を全部表示させる?いきなり簡単になるからやりたくないし
第一表示させる場所に困る。

む〜ん、まだ改良の余地があるので正式公開はしないでおきます。
しかし1回でクリアできないと、ちょっとくやしいな、これ(笑)

11月03日 難パイル、完成

難パイルがとうとう完成しました。盤面やハイスコアがセーブできないけど
そこまでする必要は無い気がするのでこのまま。

なんかこぉ悪い意味でやっちゃったなぁって気分(汗)
もうちょっとゆっくり仕上げても良かったのに一気に突っ走っちゃったよ。
これやるとまた後で更新がガクーンって止まるんだよね。
さ〜しばらくはやる気が充填するまでゆっくりするかな。

あ、それからJAVAのページ、石板庭関連は一番下に移しました。
DelphiのページにしたのにいつまでもJAVAがトップなのは
なんか変な気がしたんで。

11月05日 俺DELに乱数追加

難パイルを脱衣ゲーにしたらどうだろうか?(爆)
いや、ウソウソ。でも3ゲームですら、作った自分もきついのに
これが脱がす回数、6ゲームぐらいになったらかなり死ねるなー
でもしょぼい絵しか描けないからやらない。

11月08日 俺DELに文字列表示追加

なんだかんだ言って、こういうプログラムの概念ってものは
最初に概念を学んで後から実行というもんじゃなくて
最初に簡単なものを実行しておいて、その実行具合で概念を学ぶ
ってほうが正しいんだろうねぇ。

文字列表示の説明を作ってるうちに、そんなことを思ってました。
習うより慣れろってやつですな。
それを考えると、ゲームによるプログラム学習ってのは
授業としてもなかなかいいんじゃないだろーか?なんて思ったりして。

でも頭の固いPTAなんかに反対されるんだろうなぁ。

11月12日 俺DELに画像表示追加

難パイルを、対戦ゲームにしたらどうか?
互いに1〜8のカードを置いていき、置けなくなったら負け。
なんか必勝パターンがありそう。全手計算で解けるかも。
なら、盤面広くして持ちカードは最高5枚。
1枚使ってドローする形式にして・・・
しまった、これじゃただの変形大富豪だ。却下却下。

11月14日 俺DELにその他項目を追加。文字列間違いの訂正

色々な補助的知識が必要な気がしたのでその他を追加。
定数については変数のすぐ下にでも置こうかと思ったが
覚え始めの段階でなく、やや進んだ段階で覚えたほうが
いいものなのでこうした。

で、そろそろ石板庭でも作ろうかと思うのだが
いかんせん思っているものと現実にできそうなものに
かなりの差がある。むむぅ、技術が無いのが口惜しい。
しょうがないから今は試作版にしておいて
腕が上がってから本格版を作ることにしようかな。

11月15日 俺DELゲーで石板庭(試作)作成の開始

覚えながら、HPを作りながらで進めていってるので
かなりじわじわな進行になると思います。
まだまだ先は長いぞー

今回、ジョイスティックを外部UNITにしたから
説明が無茶苦茶長くなってしまったよ。
まだちょっと俺には早かったかなぁ?
でも一度作ってしまえば次からかなり楽になるはず。

11月18日 俺DELゲーでゲーム全体の骨組みを作ってみる

だいたいの基礎的な骨組みは完成した。ように見えたが
まだまだこれでは未完成。モードが変更された時に
一度だけ実行される処理のことを考えていないな。
例えば背景部分の処理とかね。

次回はこのことについてやってみよう。

11月26日 俺DELゲーで骨組みを完成させてみる

モード変更時の処理方法も加えてこれで正式に骨組みが完成。
ちょっと疲れた。でもいきなりぱっと画面が変わるのは目に悪いかな?

いったん暗くして明るくさせる方法が普通だけど、薄暗くするためには
半透明処理が必要だ。けど今はそんな技術は無い。
ちょっと調べたらやたらと複雑だったからDirectXでやったほうがいいかも。

とりあえず骨は終了。次からようやく内容にとりかかれます。
でもキャラの動きは上にあるから今さら説明するまでもないなー。
面データーをファイルにしてそれを読み込むのが先だね。
ファイルの読み込みにデーター形式への変換と表示。
あ、データー形式がまだ決めてないからそれを決めないといかん。
先は長そうだ。

12月01日 俺DELゲーでデーターをロードする部分を試作

意外とトントン拍子に進んでいってる気がします。
ロードもデーター変換も思っていたより簡単でした。
DELPHIってここまで覚えたらかなり楽かも。
まさか文字列から文字を一つだけ取り出す方法、
例えば変数sの5文字目の場合、s[5]だけなんて思ってもみなかったよ。

12月09日 俺DELゲーで骨組み+ロード部分+キャラ操作

HTMLでの説明が意外とめんどいな。
でも、実はゲーム作ってる時に自分のページ参照することが
何度もあったりして。まさに俺のためのってやつだな。
そして間違っていた部分は密かに直してあったりするのでみんな注意(笑)

12月14日 俺DELゲー。4方向とつかみ離し

今回から配列データーは整数にしました。
なんだかんだ言って整数データーが一番扱いやすいね。
今回はつかみ離しのみで、ブロックを動かすことはできません。
スライド部分が意外と手間取りそう。一度作ったはずなんだけどね(^^;

12月19日 俺DELゲーでルール説明とブロックの移動

ブロック移動を加えた途端、一気にそれらしくなってきました。
元々あったJAVAの時のプログラムを参考になんとか完了。

次はマークの追加ですかね。マーク表示だけじゃなくて
データーをマークつきのものにしないといけないし
文字列リストから面への変換部分も変えないといけないし
それからクリアチェックもしないといけない。
やることが多そうだな・・・

12月26日 俺DELゲーでマークを作って動かせるように

そろそろゴールが見えてきたって感じだな。
今回は意外とすんなりいけたよ。今まで積み立てていたものに
マークの部分を付け加えるだけで済んだし。

でもここまで来てなんだけど、本当にこのプログラミングの
やり方は正しいのだろうか?と疑問に思えてしまう。

世間ではやれオブジェクト指向だのなんだので
そういう方法でプログラミングしてるようだけど
ここではそんなの関係無しに組んでるしなぁ。
ま、いいか。必要になったらその時に覚えるとしましょう。

さてさて、とりあえず遊べる状態にはなったので
次はエディタを組むことにします。

 戻る