スクランブルハッチから延々と敵が出続けるバグがとれぬぅううう たぶん条件判定式のどこかで間違ってる可能性が・・・ 下方向のミサイル欲しいよね 出したいよね・・・ 凄く出したいです ミサイル発射! pic.twitter.com/cDiLFW6SAU
2020-08-15 17:22:31う~ん 一重ループならfor i in reversed(range (enemys_count))使ってリストをdelできるけど 二重ループ内でリストをdelするとエラーでるなぁ
2020-08-16 15:23:28ミサイル出た・・・・・でもスクランブルハッチの当たり判定が上部だけしか反応しないのと延々と敵を出し続ける問題が・・・ pic.twitter.com/ZcvjrbgsOq
2020-08-16 15:39:11ああ~ レーザー出したいよぉお~~ レーザービームぅううう! ???「目からビームにょ!」 目から出したいのだ!
2020-08-16 15:42:21なんの事はなかった・・・ 「スクランブルハッチ後はでアタリ判定大きくすればいいや~めんどくさいし~」 と思って後回しにしていただけの事だった・・・・
2020-08-16 15:51:35@kawamineka To manage removing sprites I mark a sprite as "sprite.destroy = True", then at the end of the update function I remove them all using the filterfalse function: self.sprites[:] = filterfalse(lambda s: s.destroy, self.sprites)
2020-08-16 17:48:45pythonのプログラミングは判らない・・・とぼやいていたところ、助言をもらったよ・・・ だけれども・・ 英語圏の方みたいで・・・ う~ん全然わからん・・・英語全然ダメなんだ・・・ 英語も数学も高校時代赤点だったし・・・
2020-08-16 17:59:31う~ん つまりスプライトを削除したいときはリストの項目にsprite.destroyって項目を作って 削除したいときにはTrue(真)って書き込んで 後で一気にself.sprites[:] = filterfalse(lambda s: s.destroy, self.sprites) って感じでスプライトリストからs.destroy項目にチェックが入ったのをdelするね
2020-08-16 18:12:30ああああ!pythonはAI機械学習向けの言語だから〇〇をリストから除いたリストを作成とか、そんな命令あった!
2020-08-16 18:13:33@kawamineka pythonは、探せば本当かゆいところに手が届くやつがいっぱい揃っているんですよね ただ、見つけ出すのが 分霊箱くらいに大変なときもある…
2020-08-16 19:26:26自分よりも敵が先にレーザービーム出したっぽい・・・ でも長すぎるとなんか変だな、敵を倒した時点でレーザービーム切れないといけないのに 何もない空間からレーザー発射される・・・ pic.twitter.com/6ORu6OFHhd
2020-08-17 00:06:04今回遷移状態を持つフラグを使って敵キャラ実装したけど 判りやすいね・・・スクランブルハッチのほうはカウントを持たせて1減少させて0になったら別のカウントをONにしてって感じでif文の連鎖で判りにくいなぁ・・どこか間違っているんだけど何所かわからないし pic.twitter.com/WkrTJu1YEj
2020-08-17 00:35:05格闘ゲームなんかは遷移状態による条件分岐が主流なんだね・・・ シューティングなら条件分岐はシンプルで多重のif文の羅列で行けるよね~~~って思っていたけど 流石に3重ifとかになるとどこが間違っているのか判らない・・・
2020-08-17 00:43:59というか・・・今は「フローチャート」という物は有ってないようなものなのか・・・ 知らなかった・・・・そんなの・・・・・
2020-08-17 00:47:09@kawamineka ハッチから ・産む前 ・産んでる最中 ・産み中 ・休み中 ・産み終わった後 がどこを通るのか調べてみるといいんじゃないですかね
2020-08-17 01:48:39@kawamineka これと同じですな >ツイート拝借 twitter.com/tk_nekoshita/s…
2020-08-17 08:29:00小ネタ。クォックスと相討ち(?)。 #ドルアーガの塔 ※ドラゴンブレスはドラゴン本体とは別に処理されています。マジシャンにとっての呪文みたいな感じ。 pic.twitter.com/40Kt4DVcbf
2020-05-17 16:37:12スクランブルハッチとミサイル関連のバグがやった取れた・・・ #pyxel pic.twitter.com/gdlXkRCG4H
2020-08-21 03:53:35それにしてもへっぽこな無駄アリアリのコードを記述しても近年のパソコンは凄まじいスピードで実行しちゃうので どこに無駄な部分があって どう改良して無駄なコードを減らせばいいのか・・ 判らないという問題が・・・ そこそこのスピードで動くからまぁ問題ないのかな?って思うけど、どうなんだろ?
2020-08-23 03:44:06unityやUEなんかだとwindows環境で無駄な処理沢山でも普通に動いていんだけれども、switchに持っていたとき処理が重くてどうしようという時 本来なら無駄なコードをなくして高速化を図るべきなのに 妥協してfps減らしとけばいいよね30fps・・可変フレームレートでも良いかぁ・・とかなるのかもね
2020-08-23 04:56:46右上方向のミサイルの当たり判定が上手く行かぬぅぅ・・ pic.twitter.com/gvJpxxpDQc
2020-08-23 04:58:05幼稚園の先生「ミネカ君!遠足に持っていくミサイルは2個までって言ったでしょ!こんなに沢山持ってきて・・」
2020-08-23 05:01:554wayマルチミサイル実装したけど・・・やっぱり上方向のミサイルの判定がミスしてるなぁ・・・ 当たり判定のy軸補正数値が上手くy軸方向に反映されてない模様・・・ pic.twitter.com/myZAgCTysh
2020-08-23 05:44:18@Pologoccha ショットの方向を臨機応変に切り替えるのが難しいんですよね そういえば東亜プランの横スクロールSTGって珍しい感じが・・・!?意外と少ない?
2020-08-23 06:02:41逆に考えるんだ・・・アッパーミサイルが上手く機能しないのなら最初から実装など無かったという事にすればいいさ
2020-08-23 06:13:49ミサイルの画像を「白い四角」にして動作を見てみる・・・ どうもアッパーミサイルだけ上に1ドットめり込んでいるので当たり判定が1ドットずれ そのため敵と当たってないと判断されている??? pic.twitter.com/sHT94LBqyy
2020-08-23 07:32:11あ~ やっぱりアッパーミサイルだけ1ドット壁にめり込んでるなぁ pic.twitter.com/aYZLvplbZP
2020-08-23 07:38:18妥協案で上手くいったけど・・・なんだか屈辱だわ・・ こんなのではまだ1流(いや2流かも?)プログラマーには為れない・・・・・ pic.twitter.com/CsvdB8t8Ek
2020-08-23 07:52:51まだなんかミサイルが壁にめり込んだり壁の中のママ直進していくバグあるけど・・見てみないふり(笑) 何だか知らんが・・・と・・とにかくヨシ!! 動いているからヨシ!!
2020-08-23 07:55:33@kawamineka 表示している位置と内部的な座標と当たり判定の為の座標範囲がずれているんじゃないかな?もしくはスプライトの大きさを間違えているとか。
2020-08-23 07:56:58しかしデバッグでfilmoraを起動するとは思わなかったなぁ・・・ レトロゲーム制作だけど開発環境は凄くモダンって感じ
2020-08-23 07:57:44当たり判定の確認時はキャラクターを四角で描画すると意外と判りやすいね・・ と。。思ったら格闘ゲームの世界では当たり前の事らしい・・・ 知らなかった・・・そんなの・・・・・
2020-08-23 08:06:11@kawamineka ミサイルが結構めり込んで敵にヒットしているように見えますので、点もしくは非常に小さいコリジョン判定しているんでしょうかね もうちょっとどちらかの判定を広くするだけでも解決しそうにも見えます
2020-08-23 08:27:16@kawamineka 横壁から突き抜けたり、めり込んだまま這ってたりするのを見ると、下向きミサイルの判定作った時点で、背景1ブロック分か弾の高さ分下が計算基準になってません? 共用するなら(絵としては少し浮くけど)ブロックの真ん中くらいに弾が来るように1/2ブロック位置を基準に±計算するといいのでは?
2020-08-23 08:35:43@kawamineka 上を這うミサイルは上の壁にピッタリ張り付いていますが 下のミサイルは壁から1ドット浮いているので コリジョン判定もそうですけど 見た目としても1ドット縦に補正が必要そうです pic.twitter.com/RHE1NBDq4r
2020-08-23 08:40:13@yazioh オブジェクト関連は全てx、y座標左上(0,0)を原点として処理するようにプログラムを組んだのが間違いでした・・・ 確かに中心部分を原点として扱っておけばあと後楽かもしれませんね・・ キャラ表示時は左上原点にして表示するって感じで
2020-08-23 08:41:29@kawamineka 四角の大きさも実際の当たり判定と同じにして コリジョン判定のバグチェックするとめっちゃ便利です
2020-08-23 08:45:54@kawamineka @yazioh 市販のレトロゲームもたいていキャラ左上が原点で扱っているので、大丈夫だと思います そもそもキャラに中心のドットが存在しないことが多く(偶数幅なので)、どっちみち左上に偏った中心座標になったりして混乱したりします… (レト2Dハードの話です)
2020-08-23 08:50:34