忍者ブログ
Profile
HN:gp-hss

職業:高校生

趣味:3DCG

言語:C全般

環境:VC++ 2008 EE

3DCG:Softimage Mod Tool

自己紹介:
ゲームプログラマー目指して勉強している者です。
現在 C++ 修得にむけて頑張っています。

Began study since 2009/8/21

Latest CM
[06/28 soulmorning]
Latest TB
(02/25)
1  2  3  4  5  6  7  8  9  10 
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

author : gp-hss ×

今回は、なかなか更新されないが今どうなってんだ?
というわけで現状報告をしたいと思います。

自作ゲームに関しては現在バトルへの継ぎ目アニメーションを新規作成し、さらにバトルモード時の画面操作のプログラムをかいています。
明日か明後日までには何とか公開できるようにしたいと思います。

忘れられているとは思いますがFF13はいまだにクリアしていません。
どうしてもゲームをする時間がとれないのです。
それに今はゲームをするよりも作るほうが楽しい。

しかしこの弱っちーパソコンは重くてならない。
当時としては少なくとも中の上レベルではあると思われるシングルコアの 2.7 GHz のCPUなのだがどうなんだろうか。
ちなみに 10 年前のものです。
OS は XP ですが、メモリは 704MB しかない・・・。
なによりストレスがハンパない。
思わず壊してしまいたくなる衝動にかけられる。
まぁ現在進行形なわけだが・・・。

では、また今度。

拍手[0回]

PR
author : gp-hss ×

test(.zip)


あぁ~とうとう学校が始まりやがった。
冬休みなんて気休めに感じるほど短いな。
睡眠時間が・・・・・・まぁ学校で寝ればいい・・・のか?

えぇ~ということで始まりました今回は、
前回のソースをヘッダーにぶち込んでいろいろと修正したものです。
たぶんヘッダーの使い方は間違っているので真似しないように。
主に敵の動作に関して改良していきました。

敵の動作をどうしようかなぁ~と考えていたところ、
「そうだ関数 y = ax は利用できないだろうか?」
ということになり、考え方としては関数のグラフと交わった座標点を敵が移動していくようにするということです。

参考画像1 参考画像2

まずは敵(◎)を原点とした関数 y = ax (右図)を取得します。
方法は、敵を表す点をEとし、主人公をHとした場合、

E(eX, eY)         H(hX, hY)
xa = eX - hX
ya = eY - hY

y = (ya / xa) * x
これで取得します。
なぜこれでいいのかは自分で考えてみてください。
この時点で敵と主人公の位置関係がわかります。
コマンドプロンプトの座標では右に行くほど x が増加し、下に行くほど y が増加します。
つまり、 xa が 0 より大きければ敵のほうが主人公より右に、 xa が 0 未満であれば左におり。
 ya が 0 より大きければ敵のほうが主人公より下に、 ya が 0 未満であれば上にいることになります。

ここから敵を動かしていくわけですが、 x の値が動かなければ y はかならず 0 になり動かないままなので、とりあえず敵を左右のどちらかに動かします。
右に動けば x = 1 、左に動けば x = -1 となります。
この場合の x とは原点を敵座標とした xy 座標においてのものです。
そして y の値を求めます。
 y が 1 以上なら下に移動させ、 -1 以下なら上に移動させます。
なぜなら、コマンドプロンプト上では下に行くほど値が大きくなり、上ほど小さくなるからです。

あとは障害物に当たったときの動作を追加していままでの処理を繰り返さしています。
いろいろとごちゃごちゃした説明でわかりにくいと思いますが、自分で図なんかを書いてみて、検証し、理解してください。

ではまた今度。


・・・・・・・ていうか・・・うわっ・・・・バカだ僕。
うわぁ~最悪だ。
このプログラムってただ主人公が上にいれば敵を上に移動させて、下にいれば下に、左にいれば左に、右にいれば右にっていうふうにやってるだけじゃん。
こんな複雑に考えなくてぜんぜん良かったわけじゃないか!
最悪だ・・・。
あっ、でもそうか。
ていうかこっちのほうがいいのか。
ただ単に移動させるのではなく、ちょうどいい感じになるように移動させられるのだから。

拍手[0回]

author : gp-hss ×

test(.c)
test(.exe)
test(.txt)


けっこういい感じに仕上がってきました。
敵を追加して、プレイヤーが敵を中心とした範囲に入ってくると敵が変な動きで追いかけてきます。
敵の挙動に関してはまだまだ修正の余地がありあまっている感じですね。
ちなみに kbhit を main 関数の while 文内だけで使用した場合、プレイヤーは敵が動いているときは動けなくなってしまいます。
なので二つの独立した動作に限りなく近づけるため、敵の移動を制御する関数内でも入力がないかチェックしています。
あと、敵の動きに関してなのですが、Sleep 関数を使っていないと処理が早すぎて一瞬でプレイヤーのところに敵が来てしまいます。
そこで Sleep 関数を使っているわけですが、この処理をとめている間にもプレイヤーは動ける必要があるため、処理の中断を細分化して、ちまちま入力がないかどうかと処理をとめる作業を交互に繰り返さしています。
ちなみに 1.3 秒処理を止めています。
これでも敵の動きはけっこう早いです。

あとはまぁ~動きの制御に関してはボール避けゲームのを流用したりしてます。
というより敵の動きの制御の実現にものすごく能率の悪い感じのことをしてしまっています。
ここもまだまだ修正していきたいと思います。
しかも、二つの独立した動作っぽいものの実現も能率の悪いように感じます。
願望としてはもっとまとめたい。

けっこうこのゲームの大枠は完成しつつありますね。
次はプログラムの能率の向上や論理的に無用な部分など修正したり追加したりしていきたいと思います。
最後はマップなどの作り込み。
結局これに一番時間がとられそうだな・・・。

ということでまた今度。

(最近わずかながらアクセス数が増えたような。まぁこの程度あってないようなもんですね・・・・・)

拍手[0回]

author : gp-hss ×

map_test(.c)
map_test(.exe)
map_test(.txt)


何かそれなりのものができました。
空白以外の部分を読み取り、二次元配列が全体像の役割をしています。
ちなみに二次元配列には宣言時、自動的に 0 で初期化されます。
あとは取得した情報を元に描画していくだけです。
もっと描画スピードを上げたいのだがそれには if 処理を取り除く必要があります。
 if 処理を取り除くためには空白も取得して、空白も描画させるという手もありますが、空白以外の部分に比べあまりに空白部が多いのであまり効果的ではありません。
または二次元配列に空白以外のところを順繰りに格納させていく方法もありますが、これだとプログラムが厄介なものになってしまい、今後プログラムが作りにくくなってしまう恐れがあります。
あまりリスクは犯したくないので、とりあえず今回はこういった形で公開しました。
案外簡単にできてしまいました。

あとは部屋ごとにナンバリングして、部屋の区別とどことどこがつながっているのか明白にします。
あとはプレイヤーが部屋の出入り口の先に進もうとしたら、いったん描画されていたものを全て空白で埋め尽くし(または空白以外の部分だけを空白で上書きし)また新たに次の部屋を描画させます。


ようやくこのゲームも先が見えてきたような気がします。
ではまた今度。

拍手[0回]

author : gp-hss ×

前回のそっけない記事申し訳ございません。
ものすごく眠かったものですから。
ファイルの解説は・・・・・まぁ大丈夫ですよね・・・。
ここはあえて解説しません。みなさんのために。
という口実のもとサボるわけですがだいたいどんなことをしているのかがわかればOKだと思います。

そして一番の難問になりそうなマップの描画についてはヒントになりそうなことを発見。
たとえばテキストファイルに長い文字列を書くと横にスクロールすることができますよね。
スクロールすると描画できる範囲外の文字は消え、また、範囲内に入ってきた文字は表示されます。
縦に長いウェブサイトも同じで、下にスクロールすれば上が消えて下に新たな情報が表示されていきます。
これを応用して、まず全体像を描画して表示する範囲を決めます。
そして、プレイヤーを中心にして自動的にスクロールがされるようにすればいけるのではないかと。
たとえば、プレイヤーが上に動けば下にある部分が表示されなくなり、上のほうに新たにマップの一部が表示されるようになるということです。
もしかしたらこういったスクロール機能はOSが提供しているのかもしれません。
まぁでも最後の手段としてはまず壁などの座標値を配列かなんかに保存しといて、プレイヤーのまわりの座標にある部分だけを表示していくということになってくるんでしょうけど。
ていうか待てよ。
確かDSとかのゼルダの伝説ってダンジョン内においては部屋を移動することでスクロールされてたはず。
これは使えるかもしれない。
出入り口や扉の座標値を保存しといてその先にいこうとするとスクロールされる、またはいったん全ての表示を消して、また新たに描画しなおすか。
描画にかんしてはその部屋の情報をどっかに保存していればできなくもないからこの方法でいけるかもしれない。
また新たに選択肢が増えたな。
けっこう道が見えてきた感がある。
うまくいけばいいが。

そういえばSDKではピクセル単位で描画が可能だけどコマンドプロンプトはやっぱりバイト単位が最小なのかな。
あぁ~早くSDKでプログラミングしてみたい。
絶対今までより充実して面白くなるはず!!
ただ今はまずこのゲームを仕上げないとな。
2月までには絶対終わらせないと。
ていうかC++の勉強が滞っているんだ・・・。
クラスの勉強にいくのにたぶんあと2週間はいると思う。
でもまぁ今勉強してるとこはCとさほど変わらないからずいずい進んでる。
3時間で1つの章終わらせたりとか。
基本読んでるだけだから。
Cのときもノートに何かを書いたことが無くてただ読んでるだけ。
でも結構読み返したりしたからなぁー、2,3回だけど。
たぶん忘れてるところけっこうありそう。
基礎が大事だからちゃんと復習しないとな。


ということでまた今度。

拍手[0回]

author : gp-hss ×
忍者ブログ | [PR]
 | PAGE TOP
write | reply | admin