« February 2006 | Main | May 2006 »

April 2006

2006.04.29

カラーラとHSPでゲームその11

結論から言おう!
データを細かくしてもガクガクは直らなかった(TT)

新規にカラーラで地形データを作り、これを1025*1025のbmpでエクスポートする。地形の方はメタセコでXファイルに変換。bmpの方はその2だか3だかで作った高さデータに変えるプログラムで変換する。
それを現在のプログラムで読み込んで、ロボ子を動かしてみた。やっぱりガクガクするんですよ(TT)
ちなみにロボ子を動かすのはaddposという命令なんだが、addpos 0,-1,0として動かしてみても別にガクガクとはならない。addpos robokox,robokoy,robokozとするとガクガクするのである。これはもうアルゴリズムとかそういう関係の問題に違いない。俺には判らない。
判らない事に悩んでいてもしょうがないので別の方法で対処するしかあるまい。
対処法としては、なるべく高さ移動は行わないようなマップ構成にする、であるな。例えばカラーラの地形作成「山と渓谷」なんてのはそのほとんどが斜面になっていてこれだとしょっちゅうロボ子がガクガクしている訳だ。そういう形にしない事にすれば良いのである。いわゆる臭い物には蓋をするのである。う~ん(^^;

もうどんどん先に進んじゃう。

次は今のプログラムを使って、地形データ上にobjを配置するプログラムを作るのである。
さて、どうなる事やら…(^^;

| | Comments (0) | TrackBack (0)

2006.04.28

カラーラとHSPでゲームその10

そもそもプログラマーと言うのは問題を捉えるセンスとそれを解決する知識の裏づけが重要だったりするとかしないとか<どっちだよ!(^^;
どっちでも良いんだ。僕、どっちも持ってへんもん<うるさいよ(^O^;

BMPから高さデータを作る時にBMPの大きさが257*257。一方、ゲームフィールドの広さが1024*1024。高さデータを読み込む時に(ロボ子座標/フィールドの広さ)*257でデータを取り出しているんだが、このときbmpデータの同じ座標に対応するフィールドの座標が出来てしまう。つまり高さが階段状になっているのである。なので段を降りる時にロボ子が縦にガクガクするのである。

ではガクガクさせない為にはどうするか?
データを均せば良い。周りと比べて平均を取るのだ。
しかし待った!下手に均すと高さデータの値も変わって地形OBJの高さと合わなくなってしまう!
さっきの計算でやると両方のXY座標が一致するのは四隅の点だけになるので、近い座標で高さが解っている所から判別しなくちゃならないのは当然だが、どの点が近いのかどうやってコンピューターに教えるか?1024*1024個の点一つ一つに257*257個の点を調べさせるのか?それだけじゃ駄目だ。座標は坂の途中に無ければならないからだ。坂のどの位置にいるかで高さも変わってなくちゃいけない。坂と言うのはベクトルだ。点が三次元のどこにいるかは二本のベクトルか、一本のベクトルと大きさと角度が必要だ。
ううう、ベクトル計算やらなくちゃいけないのか(TT)高校の数学は点が悪かったんだよ(TT)全然覚えてないし(TT)

これはやり方間違ってるな。少なくともおいらの手に余る。
別の方法を取るべきだ。
例えば…。
・・・・・・・・・・・・・・・・・・。
・・・・・・・・・・。
・・・・・。
・・。

最初から1024*1024のデータを作るべきだ!257*257のデータから変換するんじゃなくって!
257*257のデータなんて実際は地形OBJデータを作る時しか必要ない訳だし、1024*1024を257*257に変換するのはすでに出回ってる立派なソフトを使ってやれば良い訳だし!・・・・・・。ん?
じゃ、257*257を1024*1024に変換するのも立派なソフトでやれば良いじゃん!ペイントソフトで!


問題を解決する時は、頭の中で色々悩んでても大概解決しないのである。<お前は、と言う限定付だろ!
文章でこうやって書くと不思議と良い考えが浮かぶのだ。<本当に良い考えかどうか保障はしません!
良い考えかどうかは確かめてみれば判る。
もしも良い考えでなくても、それならそれでまたここに書くネタが出来るってもんだし(^O^;

読み直してみたら、解決しようとする方向が間違ってるね(^^;

| | Comments (0) | TrackBack (0)

2006.04.27

カラーラとHSPで3Dゲームその9

Gamen013


地形オブジェの実際の高さがどうなっていても高さのデータは0~255なので、データを縮めたり伸ばしたりの変換をしなくてはならない。この割合を設定する事でロボ子の高さとマップの高さが一致した。
ロボ子がXの端に来た時にずんずん昇って行ってしまう状態は、結局、移動範囲を高さデータのある範囲より小さくする事で無理やり解決した(^^;
ところがここでロボ子が移動してる時に縦にカクカクする問題がかなり手ごわかった(^^;いや、過去形で話してはいけない。手ごわいのだ!
これは本格的に移動ルーチンの見直しか(TT)
あるいは高さ移動する時は別ルーチンにするか。
そっちの方が楽そうだな。
しかしそうやって楽な方へ、楽な方へと向かってると後でしっぺ返しが起きそうだなぁ(^^;

ま、アレです。
水平移動(ただし4方向(^^;)だけなら何も問題ない訳だから、3Dすごろくゲームとかならもう作れるな<それはどうかな?

| | Comments (0) | TrackBack (0)

2006.04.26

カラーラとHSPで3Dゲームその8

アレから色々考えた。
高さデータはBMPで保存するとして、他のオブジェ(木とか岩とか小屋とか)のデータはどうしよう?それもBMPに色のデータとして置いとくのか?そもそも配列変数がセーブできないなんて、プログラム言語としては致命的なんじゃないか?おかしい、絶対おかしい。

間違いと言うのは、自分で正しいと思っているから間違いなんである(^^;間違ってる時は自分で間違ってないと思ってる所が間違っているのである(^O^;
パソコンを知らない人が、インターネットが出来ないからパソコンが壊れていると思って、実は電話線が繋がってない、と言うアレである。
ハッハッハ(^O^;

配列変数の添字(A(x,y)の、xとyの部分が添字だ)と言うのは、特別な宣言をしない限り整数が使われる。変数mapの添字にロボ子の座標を使おうと思ってmap(robokox,robokoy)とやったのがいけなかった。ロボ子の座標は実数なんであるよ(^^;それで型があってませんとエラーが出たのである。尤もだ(^^;ここを整数に直してやったらちゃんとデータが読めました。
そーだよなー。配列変数がセーブできない訳無いモンなー(^^;

ところでHSPで3Dゲームをやるならなんで「Esay3D for HSP2.61」を使わないの?と思われるかもしれない。(そういうフリーソフトが有るんである。3Dゲームを作る様の)
HSP3.0でやりたいからである。(HSP2.61とHSP3.0は互換性が低いのである)
あと、自分で悩んだ方が面白いから、と言うのもある。
もっともROKDEBONEはそのEsay3Dの人のツールなんだけど(^^;
Gamen010
Gamen011
Gamen012

さて。
データのセーブとロードが出来たんで、マップエディターを作る前にどういう風に動くんだか試してみた。高さのデータが257*257、フィールドの広さが1024*1024なので(座標/1024)*257で大きさを合わせてやる。多少カクカクするだろうがそれは後回しだ。
うーむ、高さの比率が合ってないな。それにXのプラスの端に達するとロボ子がどんどん昇って行ってしまう(^^;
どっちもだいたい原因はわかる。
でちょっと治してみるが治らない~(^^;あれ?
おかしいな。ひょっとしたら根本的に移動ルーチンが間違っている可能性が(^^;あれ?

| | Comments (10) | TrackBack (0)

カラーラとFSで3Dゲームその7

カラーラの地形オブジェクトを作る時に使う白黒のBMPファイルをHSPで読み込んで、そのBMPの画像の輝度から高さデータの2次元配列変数を作る所までは出来た。
ところが!
なんとその出来上がった配列変数をセーブして、再び読み込もうとしたら「変数の型が違います」とエラーが出た。あれ?
どうやらbsaveとかbloadとか言う命令は、配列変数の内容(順番とかどの要素かとか)を崩さずに読み込んだり保存したり出来ないみたいだ。
ちなみにHSP3.0についてくるサンプルプログラムで配列変数を保存したりしてるんだが、おいらにはそのコードが何をやってるんだか全然判らない(^^;
さあ困った!

さて。
多分、世のプログラマー養成期間では、美しいプログラムを書くように、と指導している筈だ。
美しいプログラムとは、構造や記述がすっきりしてるとか、数式を上手く活用してるとか、無駄な処理が省いてあるとかそういう事だ。
しかし!
プログラム言語を触るすべての人種が、職業プログラマーになる訳じゃない。個人で楽しむプログラムに美しさなんか必要ないのだ(^^;
素人プログラマーが心がける事は一つ。難しそうな処理は簡単な処理に置き換えろ!である<偉そうだな(^^;

さて、それじゃ、どうするか<聞いて呆れないように(^O^;
プログラムの最初にBMPを読み込んで高さデータを作成すれば良いのだ!<MAPが切り替わるたびにそれをやる気か(^O^;
やる気なのである。
どうせ売り物じゃないし、なにかのコンクールに出す訳じゃないし、自分で楽しめれば良いんだし(^^;<典型的な言い訳(^^;

| | Comments (0) | TrackBack (0)

2006.04.24

カラーラとFSで3Dゲームその6

さて(^^)
ロボ子も平らな所なら自由に走れるようになった。4方向だけど。
しかし3Dゲームなら高低差のある所も走れるようにならないといけない。その為には2つの方法が考えられる。
1:地面との衝突判定で高さを変える方法。
2:高さのデータが記されたマップを用意しておいて、それを元に判断する方法。

これがねー(^^;
素人はついつい1番の方法でやろうとするんだけど<って、お前だって素人じゃんかよ!<すまん(^^;
実はオブジェクトのポリゴン1枚1枚で衝突判定をするのは大変らしいのよ。まず、そんな機能を持ったソフトは無い、らしい。
3Dゲームで衝突判定をする時は、対象をボックスなり球体なりで範囲を囲って、その範囲同士が接触した時に衝突を検出する、と言う方法が一般的らしいよ。その方が簡単みたいね。
こういうの、シューティングの弾が当たった時、とかに使う方法で、地面相手では色々不都合が有るのだ。

2番の方法は一見、別のマップを用意しとくなんてめんど臭そうだが、実はこの方が考え方的に簡単。
キャラクターのXY座標(HSPではXZ座標)を見てその位置のZ座標(HSPではY座標)を読み込む。シンプルだ。
なので2番の方法で行く事にするのである。

さて、そうすると。
その高さのマップをどうやって用意するか、である。
まさかいちいち調べて手で打ち込んでいく訳にもいくまい。
そこで、簡単なエディターを作らねばなるまい。
どういうエディターか?それも二通り考えられる。
3:マップの大きさに対応したBMPファイルを用意してそのドットの濃淡で高さを決める方法。
4:高さの定まっている地形ブロックを組み合わせて地面にする方法。

3番は割りとおなじみなんじゃなかろうか。カラーラの地形エディタなんかその方法だし、景観作成ソフトなんかでも地形を作るのにそういう方法を使う。
エディタの作業としてはペイントソフトのような機能を持たせて、それを高さマップとして吐き出させれば良い訳だ。
実際の地形モデルはカラーラなりなんなりで造れば良い。
問題点としてはエディタだけで作業が完結しない所だな。

4番の方法は、まあブロック遊びみたいな物だからイメージが掴みやすい。前もって用意しておくブロックのモデルは、箱と断面が直角三角形の三角柱の2種類を用意すればよいだろう。
エディタの作業としては良く有るRPGのマップエディターと変わりは無い。どのモデルをどの向きで置いてあるかを吐き出しとけば、このモデルだったら高さはこう、とソフトで対応させておけば良いだけだ。
問題点としては、この方法は狭い場所に向いたマップの造り方だ、という事だ。ダンジョンとか屋内とか。広い平原とか大きな山とかには向かない。

実は、3DRPGツクールではその両方のエディターを装備していて、ダンジョンと平原を使い分けている。
なので、素人のあっしとしては<ほらやっぱり!
それに倣っとくのが良いだろうな。

さて。
3番と4番。どっちが簡単だろう?簡単な方からやろう。
3番の方が簡単かな?BMPから高さに変換するコンバーターだけで良さそうだし。良く考えたらBMP作るのは今あるペイントソフトで良い訳だしね。
で3番で上手く行ったら、4番に対応させる。そうすればマップ上に他のモデルを置く配置マップとしても使えるかもしれないし。
なんか有ったら作ってる時に考えればいいや(^^;<だからプログラマーとしては素人なんですってば!

| | Comments (0) | TrackBack (0)

2006.04.23

カラーラとFSで3Dゲームその5

Gamen008
Gamen009


ロボコ(プレイヤーキャラクター。仮名)にアニメーションを付けた。
メタセコイアでロボコのモデルに線形状のボーンを作っておき、ROKDEBONEと言うFS(フリーソフト)に読み込ませてボーンを適応させる。
このFSが優れ物で、この設定したボーンでアニメーション(ポーズ)を設定できる。そこからアニメモーションファイルを吐き出して、RDB2Xと言うFS(同じ作者の作品だ)で、アニメーション付きXファイルに変換できる。
作者は将来的にROKDEBONEで、アニメーションXファイルも出力できるようにして下ったら嬉しいなぁ。お願いしますm(__)m<直接お願いしろ!
で、これでアニメーションするロボコが出来たわけだ。これをHSPで組んだプログラムに組み込まなくちゃならない。
まず入力待ちのポーズだが、これは簡単。最初に読み込んだ時点で表示される。
問題は移動中の走りポーズだ。
カーソルキーの↑を押してる間、走るように設定したら、走りアニメの最初のフレームでポーズが固定されたまま移動してしまう。
*mainルーチンがループになっているので、ループされる度に走りアニメに切り替わるのが原因だ。
これはアニメを切り替えるobjact命令の3番目のパラメータを1にすると、前回のアニメが終了してから切り替わる様になるので解決する。
だが別の問題が発生した(^^;
走り出したり止まったりする時のアニメの切り替えのタイミングが遅れるのである。(待機ポーズのまま地面を滑って行ったり、その場で走り続けたりするのである)
これはどうしよう(^^;
思いつかない(^O^;
そのままにしとくか<おい!

| | Comments (0) | TrackBack (0)

2006.04.22

カラーラとFSで3Dゲームその4

Gamen007


キー入力のところを変更した。
画面では判らないか(^^;
カーソルキーの→←↓を押すと変数mukiの値が変わるようにして、↑キーを押した時に変数mukiの値を見て進む方向を決めるようにした。これで取り合えずOK!(^^)
アクションゲームならこれではすまんだろうなぁ。でもアクションゲームじゃないから良いのだ(^^;
三角関数は使ってないから判り易い<のか?
それと、ちょっとコスチュームを変えてある。あんまりだったからね。
前後左右に動けるようになったので、次はアニメーションファイルを作らなきゃな。
これも専用のFSでXファイルを作らなきゃならない。カラーラのボーンは使えないのである。当然か(^^;

| | Comments (0) | TrackBack (0)

2006.04.21

カラーラとFSで3Dゲームその3

とりあえずキーボードでモデルとカメラが動くようにしたのである。
理想としてはカーソルキーの↑を押すと、正面に進み、→と←で方向転換、↓で後進、と言う風にしたかったのだがやり方が解らない(^^;

あ、今解っちゃった。向きを変えたらキー入力の所を変えればいいのかな?すると東西南北で4種類のキー入力処理ルーチンが要るのか(^^;<なんか効率悪いな。こういうのはきっと簡単にする方法があるんだろうな。

ま、とりあえず、現段階ではカーソルキーの上下左右がマップの東西南北に対応してて、そっちの方向にモデルが進む。ここまではまあ普通。
普通じゃないのは、文字キーでカメラの位置を変えられるようにしてしまった事だ。カメラの位置を変えても注視点モードになっているから、モデルがいつも画面の真ん中にいるのは良いんだが、見ていて画面のどっちが北だか南だか解らなくなってしまったのだぁ!(^^;
これはまずい!
一応”Q”キーを押すとカメラの位置が元に戻る様にしてあるが、これは全然まずいなぁ。前に進もうと思ったら右に進んじゃったりするのね(^^;
かと言ってほら。3Dゲームなんだから回りを見回せない事には話にならないしね。

しょうがない。方向で4種類のキー入力、作るか(^^;
きっとたいした手間じゃない。<それはどうかな?

Gamen004
Gamen005
Gamen006

それにしても、昼の間はモデルを中心にしてカメラを回そうと思ってて、本屋で高校数学の図形と方程式の本まで買ってきたのに。役に立ててないな(^^;微分積分の方が役に立ったんじゃなかろうか?
まあ、その本、面白かったから良いんだけど(^^;
高校の時は数学の点、悪かったモンなぁ。<高校の時も、だろ!(^O^;

| | Comments (0) | TrackBack (0)

2006.04.19

カラーラとFSでゲームその2

Gamen001

とりあえずHSPで3D表示が出来るようになった。
こうして見るとそれっぽいでしょ?<凄い昔のポリゴンゲームみたいだ(^^;
ちょっとモデルの手を抜き過ぎの様な気もするが(^^;とりあえずプログラムで3D表示をするのは初めてなので、色々確かめながらやっていかねばならんのだ(^^;<言い訳だ
今は背景ごとモデルをぐるぐる回しながらカメラを寄せたり引いたりしてるだけだが(カメラに注視モードというのが有って助かる)、そのうち、キーでモデルを移動させたり、カメラの視点を変えたり出来るようにしなくちゃならない。
ううう、楽しい(^^)
Gamen002
Gamen003

| | Comments (0) | TrackBack (0)

2006.04.17

CARRARAとフリーソフトで3Dゲームを作る

何もしないで世界を歩き回るようなゲームが好きだ。
もっともゲームの事は(特に最近のは)詳しくないのでそういうゲームがあるのかどうか定かでない。
DQの7なんかかなり近いんだが、アレはモンスターと遭遇して邪魔だし。
実は3DのRPGツクールも持ってるんだが、操作はPS2のコントローラーだし、記憶媒体がメモリーカードだしで(PS用のキーボードとかHDとか持ってない)、いまいち使い辛くて挫けてしまった。
で、HSPだ。
ツクールで挫けた奴がプログラミングでそんな物作れるのか?とも思うけど(^^;
昔ベーシックはやった事があるんで(趣味でだからたいした事は無いが)HSPのソースならなんとなく判る。
問題はどうやって3Dデータを持ってくるかだけど。
六角スーパーから吐き出したX形式のファイルは、どうやらUVを指定したモデルだと1メッシュのデータにならないらしく、HSP側で表示できない。
CARRARAはX形式のファイルは吐き出せない。
試行錯誤の結果
六角スーパーでいつものようにモデルを作り、CARRARAに持って行っていつもの様にテクスチャを貼る。ただしテクスチャは1モデルに1枚。ローポリを心がける。
で、このデータをテクスチャ無しのOBJファイルにしてメタセコイアに持って行く。
この時、テクスチャ無しでもOBJデータにはUV情報が付加されているので、メタセコ上でテクスチャを貼ると同じように貼られるのである。
で、メタセコからX形式のファイルを吐き出すとちゃんとHSP上でテクスチャ付きで表示された。
ROKUDEBONE(だったかな?)というフリーソフトでボーンも入れられそうだし。<まだやってないけど。
フリーソフト様様だ。そういやHSPだってフリーソフトだしな。
後は根気だな(^^;

ところでどんなゲームにする気かって?
怪獣の居る島で、歩き回って怪獣を眺めてるゲームである。
うーん。普通の人は面白くないかもね(^O^;

| | Comments (0) | TrackBack (0)

« February 2006 | Main | May 2006 »