忍者ブログ

カレンダー

01 2025/02 03
S M T W T F S
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28

最新コメント

[07/13 ♀はっか]
[07/13 ♀はっか]
[07/11 ♀はっか]
[07/11 ♀はっか]
[03/16 空竜]

最新トラックバック

プロフィール

HN:
空竜
性別:
女性

バーコード

ブログ内検索

アクセス解析

忍者アナライズ

[PR]

×

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

結論。反応に困る。

本日は晴天なり。
心は常雨天なり。

嘘です。
何が、とは言わないけど。
嘘です。

今日は。
泣き疲れました。
いつものことだけども。

こういう気分の時って、なんか天井に立ってる気分になるんだよね。
というか、重力に逆らってる気分?
むしろ足に鎖結びつけられて宙ぶらりんになってる気分?
いや、とにかく天地逆転状態気分。
天の邪鬼って感じなのかな。
重力という自然物にすら逆らってる、みたいな。
別にそんな深く考えてイメージしてないんだけどね。
なんかこう、深い意味なく天地逆転してる感じなんだよ。
なんだろね。

そうそう。
高校時代からグチグチ言ってるけどさ。
肺が痛い。
お前またか、と言わんがばかりに。
でもそういえば、前みたいに耳鳴りゴォォォとか、
突然心臓バックンバックンとかはなくなったよね。
まあ、実は原因は知ってるんだけどね。
寝てる時に、意識を地面の下まで埋もれさせると、あぁなる。
最近は意識飛ばしやってないしね。
結構楽しいんだけどね。負荷が多いわけだよ。

前からオレの描くラクガキは天地が分からないようなものだったり、
地面に足がついてないようなものだったりするけども。
オレの頭ん中が地面に足付いてないせいかもね。
夢の中ですら地面に足付いてなかったりするしね。
よく家の中とか家の前でフヨフヨしてるし。
ただ、夢ん中だとあんまり制御効かないんだよね。
横移動はすんなりだけど、上に直角で飛ぶのは結構大変。
まあ制限あったとしても、実際にフヨフヨできた時とは感覚全然違うんだろうね。
風だとか、自分にかかってる力の加減とか。
って、何の話か。

他人の見てる世界ってのは、ホントどうなんだろうね。
こんな感じでグダグダ生きてるオレってのはさておいて。
今どういう気分で、どういう想いで、どういう夢を見てるんだろうね。
でもって、もしオレの気分だとか、想いだとか、
夢を目撃したとするなら、どういう評価を下すんだろうね。
・・・OK。んじゃ仮に、オレがオレを目撃すりゃいいんだね。
そういうことだね。了解。

はい。
目の前に天地逆になった顔があります。上を見上げれば胴体、手足。
でもって薄目で半笑い。
・・・。
ちょっとビンタしてみる。
半笑い。
おぉ。キモイ。
髪の毛引っ張ってみる。
目を瞑った。何。痛いの。なんなの。
結論。反応に困る。

何か浮いてます。
・・・。
掴んで、おもっきり投げる。
どかーん。
がらがら。
結論。反応に困る。

気分を、知りました。
いろいろ愚痴られました。
首絞められて、殺されかけました。
今オレは他人です。
他人に何かを言う権利はありません。
結論。反応に困る。

分かった。
分かろうとしても、分かったとしても、意味ないのね。
よーく分かった。
でもこういう状況だと・・・
世の中のやりとりって、ホントどうやって行われてるんだろ。
協力とか信頼とか、理解不能すぎてどうしようもない。
オレが馬鹿だから、と言えば間違いなくそうなんだけども。
評価基準となる原点が原点にいることを拒否してるからいけないんだろうか。
そんな気もする。
まあ別にあの人の在り方を拒むには動機不十分だけど。

拍手

PR

無駄なことを考えるのはいつものこと


大事なことは。
当たり判定部分と描画部分を各自まとめて管理したい、ということ。
画面全体で何がどこにあるのかを毎回把握することじゃない。
だからこそいつだって。
for文グルグル回して、プレイヤーと敵との当たり判定を取るわけで。
そのfor文の回数を減らすようなことは考え出せばできなくはない。
エリアごとに区切って何処に何があるか
把握した上でfor文回そうかとか考えたけども。
本来の目的じゃない。
だからもっと単純に考えればいい。
やりたいことは一括管理であって最適化じゃない。
落ち着け。

で。更に突き詰めると。
一括管理をしてどういうメリットがあるのか。
そもそも何が嫌なのか。
嫌なこと。そう。
同じ画像を使用した、違う動きの敵を作った時に、
毎回毎回当たり判定の大きさだとか、画像のサイズを
設定しなおさなきゃいけないこと。
さらには、地面に着地したいだけでも、毎回各自が持ってる
画像サイズを考慮して座標を決定しなきゃいけないこと。
挙げ句、座標の設定に失敗して壁にめり込むと、
当たり判定が効いて自滅すること。
で。
それを解消しようとしたらどうしたらいいのか。
画像に対して設定しなきゃいけない読み込みサイズだとか、
当たり判定の大きさを全部どこかでまとめて決めてしまうわけで。
「コイツの隣にコイツを並べようとしたらどうすればいい?」とか。
難しい処理なしでできれば便利。
やりたいけどね。
それを作ることの方が難しかったりなんかして。

拍手

馬鹿が考えると無理難題になる

今日は。
なんだっけ。講義受けて・・・即帰り。
帰って来てから・・・またシューティングいじって。
そう。
どう改造するか決めてた。

で。
こうした方が便利かな?の繰り返しで、どえらいことになってしまった。
入力コマンド管理とプレイヤーの表示画像管理を別のクラスでやるってのも、
まあ無茶というか、無駄というか、なんだけども。
画面に表示する画像すべてを別クラスで管理とか、
画面上の当たり判定をすべて別クラスで管理とか、
思い立ったはいいものの、改造量が壮大すぎる。
でもそうでもしないと、正直馬鹿なオレにはやりにくい。
特に当たり判定。

各画像の当たり判定範囲の情報として必要なのは実質
判定を取る大きさと、座標と、あとはその判定の有効無効だったりする。
判定を大きさが変わる時ってのは、画像そのものがデカくなることと同意とすると、
わざわざ巨大化するためだけに画像を用意するような特例なわけで。
そういうことは今回する予定もないし、大丈夫だろうということで。
そういう状況で、だよ?
個々のクラスで生数値打ち込んで当たり判定の大きさを
設定しなきゃいけない現状がどうも気に入らない。
ゲーム全体として、どういう当たり判定を持ったものが
ステージ上にあるのか、把握しにくくて仕方がない。

我思うに。
「現在の画面のこの部分には今一体何がありますか?」と聞かれて、
「これとこれがあります」とか返してくれた方が断然いい。
返答によっての動作は受け取った側で決めるとして、
そこにあるすべてが何か分かるような状況の方が、断然分かりやすい。
プレイヤーも敵もブロックも。あるいは敵とブロックの各種類すら。全部。
破壊できるできない、当たると死ぬ死なない、それ以上移動できない。
そういうことは後で考えることであって、そこにあるかないかという問題の方が先。
・・・だと馬鹿は思うのです。

そこを全部管理するとなると、表示する画像の大きさだとか
位置も、一括で管理してしまえばいい。
各画像の位置の移動は各クラスで行うにしても、その移動によって
当たり判定位置がどう移動したか把握しなきゃいけない。
ということは、画像がどう移動したかも把握できる。
どうせ画像の大きさも設定しなきゃいけないんだし、
先に画像の初期設定を全部済ませてしまうクラスを作ってしまえばいい。
移動先の座標だけ設定して、指定されたものを移動させるだけ。
もし表示する画像のタイプを切り替えるのなら、
切り替える画像のインデックス値とか、アルファ値とかだけ受け取って、
それを反影させた方が、オレ的にはやりやすい。

そうなると、画面上に表示するものには種類別IDが必要になる。
でも、それで一括管理できるのなら、それに越したことはない。
「その種類のオブジェクトはこの画像で、この当たり判定のサイズです。
移動や画像変更あればどうぞ。あ、今これと重なってますよ」
とか。そういう感じ。
言うのはいいんだけどね。結構厄介なんだよね。
画像の読み込み場所と、画像の移動はそれぞれ別クラス。
当たり判定も各クラスで当たり判定サイズを持たせておいて、
そのサイズを参照しては当たってるか判定、当たってるか判定。
オマケに、複数の敵とか、複数の弾との当たり判定も、ループ管理状態。
そう。ループで管理してるからこそ、画像が重なっていても、
一つ一つを管理することができるわけで。
それをまとめて管理するとなると、どう実装するのか。
・・・。
考えればできそうな気もする。
画面内オブジェクトの個数管理と種類管理、座標管理っしょ。
逆算して当たり判定範囲が出せるし・・・
うん。多分。
出来ずに自滅してやる(そっちかい)

拍手

続・ドットドッタードッテスト

朝からガタガタ打ってました。
シューティングの仕様。
こうした方がいいよね多分。
これありかも。これできるといいかも。
こうなってこうなってこうなればいいよ。
こんなの出ていいんじゃね。
等々。
おかげさまでシステム部分大改良決定。
いや、基本的な部分の考え方は現状のヤツでいけるんだけども、
読み込む画像のサイズやら、それに合わせた当たり判定やらの調整とか。
画面のスクロールスピード変化とか、スコア関連の応用と調整とか・・・
まあ、大まかな仕様は固まったっぽい。

で。
その後は、またまたドットドッタードッテストでした。
さて。できた部分を後に付け足して・・・



現在計22枚。
・・・ご、ごめんなさい。
最初に思いついたモーションがコレだったんです。
「横スクロールシューティングゲーって、左から右に流れる・・・んだよね?」
はいごもっともです。
いや!ちゃんと前向きにも打つよ!まだ作ってないだけなんだよ!
ただやっかいなんだって!
移動しながら打たれるとホント、ホント。
ま、移動制限なしは貫通弾だけにするつもりだから、
上下連射は多くても8枚程度に抑えられる、はず。
あぁ、この調子で続けて大丈夫なんだろうか・・・
実装できずに終わりそうだ(汗)

拍手

繋ぎ方いろいろ、重ね方いろいろ。


繋がりなんてものは脆くて。切ろうと思えばすぐに切れる。
そんなものに一喜一憂してたらキリがない。
それに。
向こうが切ったのなら、こっちから繋ぎ直すようなマネは勝手な判断だ。
オレには繋ぐ権利もなければ切り離す権利もない。
というか、そんな権利あっても欲しくない。
求められない意見はただの我が儘だ。

今日は。
ゼミ生の子と2人で。
教授が事前に用意したプログラムを眺めつつ、
課題のプログラミングについてやいやい言ってた。
ら。
「こっちで引数になってたから、こっちにも引数として持って来たんけどさ・・・」
「あ〜なるほど。そうするんか」
「・・・なぁ」
「ん?」
インターンでの相方が後ろからヌッと現れ一言。
「・・・それ、g(=クローバル変数)で宣言されてるで」
「・・・」

「はあぁああ?」

「え、ちょっとまって。こっちで引数に入ってるのに、グローバルもあんの?」
「そう」
「どこ!?」
「このヘッダーファイルの・・・」
「・・・ほんまや。externある・・・なんでだ?意味なくね?」
「constかそうでないか、という差はあるけど」
「いやいやいやいや!constにしたってグローバルで呼び出したら一緒やん!」
「う、う〜ん」
「おぉぉぉぉ・・・この馬鹿には意味が分からんぞ・・・」
「教授の優しさ、とか?グローバルの方が使いやすいし・・・」
「それにしたって今まで使ってるのも引数の方やん」
「いや、そうやけどさ・・・」
「・・・プロジェクト内検索かけたろ」
「ど、どう?」
「ちょ!検索引っかかったん2個だけやん!こっちでは引数の方使ってるし!!」
「それきっと教授がなんか改造しようとしてやめたんやって・・・」
「半端すぎる・・・!!!」

結論。
システム改変も含め、オレは最初から組み直すぞ。

拍手