質問コーナー3

sypu

lovekaraage wrote:
滑らかに動かしたり　ジャンプさせたりりするのはどうすればいいのでしょうか

#1を読んでください。

質問する前に
2.同じような質問がないかを調べましょう。

sky_77

YY04 wrote:
lovekaraage wrote:
滑らかに動かしたり　ジャンプさせたりりするのはどうすればいいのでしょうか
ジャンプの件は、もうすでに出ています。

ジャンプはここですね。
滑らかに動かすサンプルを作りました。

SCRATCHER___K

どうすればプロジェクトが人気になりますか？

(知名度あげたーーーーーい)

YY04

SCRATCHER___K wrote:
どうすればプロジェクトが人気になりますか？
(知名度あげたーーーーーい)

スタジオを作って作品を入れたり、ここで宣伝したりしてはどうでしょうか？

s-t-p

ラストポスト切れが発生したのでダミーで投稿します。

Last edited by s-t-p (June 16, 2019 06:18:29)

KimiruHamiru

lovekaraage wrote:
滑らかに動かしたり　ジャンプさせたりりするのはどうすればいいのでしょうか

lovekaraageさんページを見ると、
「いろいろなアクションゲームのプロジェクトのコードを見たけど、複雑で読み取るのが難しかった」
ということなのかな、と思いました。

「アクションゲームとして面白いプロジェクト」、「完成したプロジェクト」のコードを読み取るのは、難易度が高いです。
Scratchには、コンピュータのプロのオトナでも読みこなせないようなプロジェクトも結構あります。

完成品じゃなく、「ジャンプの説明のためだけに作られたプロジェクト」というのもあるので、
ScratchWebサイトで「ジャンプ」で検索して「いまいちゲームっぽくない画面」のを選ぶと見つかるかも知れません。
Webで「Scratch ジャンプ」で検索するのもおすすめです。

たくさんコードとその動きを見て行けば、短い、読みやすいコードもあるはずなので、そういったコードを読んでみるのがいいかなと思います。

ジャンプの仕方は何種類もあって、ジャンプのコードも何種類もあって、正解はというのは、人によって状況によって違います。
いろんなコードを見て、丸写ししたり改造したりを繰り返して、

何が同じで何が違うのか
どういう時そういう動きを選ぶといいのか
自分の知っているゲームはどれに似ているのか

とか考えていくと、手掛かりが見つかって、複雑なコードやフォーラムで示されるサンプルコードとかも使えるようになると思います。

KimiruHamiru

lovekaraage wrote:
滑らかに動かしたり　ジャンプさせたりりするのはどうすればいいのでしょうか

「滑らかに動かす」というのは結構深い話です。

「元の絵と似た絵に、素早く入れ替える、と、動いているように見える」
というのがアニメーションの仕組みで、テレビとか実写映画とかゲームとかも基本的には同じです。

「元の絵と似た絵」というと
１）「元の位置とどれくらい違うか」
２）「予想の位置とどれくらい同じか」
「素早く入れ替える」というと
３）「絵を入れ替えている作業を短時間で済ませる」
４）「絵を入れ替えている作業の途中の状態を見せない」
とかいった要素があるかと思います。

１，２，３，４につてい細かい説明は、書いてみたらとんでもなく長くなってきたのでやめておきますが、Scratchに限定せず「手書きアニメーション」とかについてWebで検索して調べると「滑らかな動き」について、見えてくることも多いんじゃないかと思います。

Scratchの場合「画面更新は1/30秒に１回」、「スプライトの描画を伴う操作は原則１フレーム消費」、「定義ブロックはフレーム更新抑制できる」、「メッセージ処理中は画面更新しない場合がある」とか固有の注意点もあるようですが、話が広がりすぎるので、実際に自分でコードを書いて動かして、「この書き方」だと「重い、カクつく」とかいった体験をしてから調べた方がよいと思います。

inoking

KimiruHamiru wrote:
「メッセージ処理中は画面更新しない場合がある」

これは知らなかったのですが、もう少し詳しく教えてもらえませんか。

kasagaha

KimiruHamiru wrote:
lovekaraage wrote:
滑らかに動かしたり　ジャンプさせたりりするのはどうすればいいのでしょうか
「滑らかに動かす」というのは結構深い話です。

「元の絵と似た絵に、素早く入れ替える、と、動いているように見える」
というのがアニメーションの仕組みで、テレビとか実写映画とかゲームとかも基本的には同じです。

「元の絵と似た絵」というと
１）「元の位置とどれくらい違うか」
２）「予想の位置とどれくらい同じか」
「素早く入れ替える」というと
３）「絵を入れ替えている作業を短時間で済ませる」
４）「絵を入れ替えている作業の途中の状態を見せない」
とかいった要素があるかと思います。

１，２，３，４につてい細かい説明は、書いてみたらとんでもなく長くなってきたのでやめておきますが、Scratchに限定せず「手書きアニメーション」とかについてWebで検索して調べると「滑らかな動き」について、見えてくることも多いんじゃないかと思います。

Scratchの場合「画面更新は1/30秒に１回」、「スプライトの描画を伴う操作は原則１フレーム消費」、「定義ブロックはフレーム更新抑制できる」、「メッセージ処理中は画面更新しない場合がある」とか固有の注意点もあるようですが、話が広がりすぎるので、実際に自分でコードを書いて動かして、「この書き方」だと「重い、カクつく」とかいった体験をしてから調べた方がよいと思います。

滑らかに動かすだと、滑るように歩くということなので、コスチュームを変えずに歩けばいいと思います！

kasagaha

KimiruHamiru wrote:
lovekaraage wrote:
滑らかに動かしたり　ジャンプさせたりりするのはどうすればいいのでしょうか
「滑らかに動かす」というのは結構深い話です。

「元の絵と似た絵に、素早く入れ替える、と、動いているように見える」
というのがアニメーションの仕組みで、テレビとか実写映画とかゲームとかも基本的には同じです。

「元の絵と似た絵」というと
１）「元の位置とどれくらい違うか」
２）「予想の位置とどれくらい同じか」
「素早く入れ替える」というと
３）「絵を入れ替えている作業を短時間で済ませる」
４）「絵を入れ替えている作業の途中の状態を見せない」
とかいった要素があるかと思います。

１，２，３，４につてい細かい説明は、書いてみたらとんでもなく長くなってきたのでやめておきますが、Scratchに限定せず「手書きアニメーション」とかについてWebで検索して調べると「滑らかな動き」について、見えてくることも多いんじゃないかと思います。

Scratchの場合「画面更新は1/30秒に１回」、「スプライトの描画を伴う操作は原則１フレーム消費」、「定義ブロックはフレーム更新抑制できる」、「メッセージ処理中は画面更新しない場合がある」とか固有の注意点もあるようですが、話が広がりすぎるので、実際に自分でコードを書いて動かして、「この書き方」だと「重い、カクつく」とかいった体験をしてから調べた方がよいと思います。

ジャンプだと、

定義 簡易的ジャンプ
(10) 回繰り返す
y座標を (10) ずつ変える
end
(10) 回繰り返す
y座標を (-10) ずつ変える

end

Last edited by kasagaha (June 16, 2019 10:31:20)

inoking

kasagaha wrote:

ジャンプだと、

定義 簡易的ジャンプ
(10) 回繰り返す
y座標を (10) ずつ変える
end
(10) 回繰り返す
y座標を (-10) ずつ変える
end

試してみると分かりますが、
「簡易的」とはいうものの
これはただ上下しているだけでジャンプに見えません。
同時に横移動させると不自然さがよく分かります。

ジャンプするなども参考になります。

KimiruHamiru

inoking wrote:
KimiruHamiru wrote:
「メッセージ処理中は画面更新しない場合がある」
これは知らなかったのですが、もう少し詳しく教えてもらえませんか。

うわ突っ込まれちゃいましたね。表現が乱暴だったかもしれません。

私が想定してたのは

このスプライトがクリックされたとき
隠す
(30) 回繰り返す
[自分自身 v] のクローンを作る
end

クローンされたとき
[どこかの場所 v] へ行く
表示する

といったコードでは、30フレーム消費されるけど、

このスプライトがクリックされたとき
隠す
(30) 回繰り返す
[自分自身 v] のクローンを作る
end
[メッセージ1 v]を送って待つ

クローンされたとき

[メッセージ1 v]を受け取ったとき
[どこかの場所 v] へ行く
表示する

と書くとほぼ１フレームで処理が完了する、つまり、

「メッセージの処理中」は画面更新しない(各クローンが１フレーム消費して30フレーム１秒かかったり、一部のクローンだけ先に表示された状態になったりはしない)で遅延される
＝「メッセージの処理完了時」に（＝「メッセージ1を送って待つ」ブロックの実行完了時に）画面更新される

といった話でした。
scratchのフレームレートについて調べていた時にWebで見たと思うのですが、今探したらちょっと見つけられませんでした。

メッセージを受け取った側で複数フレームのアニメーションをしようとすると「経過が表示されず最終結果だけ表示されたり」で悩んだことがあったように思います。

参考：
https://scratch.mit.edu/projects/292731581/

KimiruHamiru

inoking wrote:
kasagaha wrote:
ジャンプだと、
定義 簡易的ジャンプ
(10) 回繰り返す
y座標を (10) ずつ変える
end
(10) 回繰り返す
y座標を (-10) ずつ変える
end
試してみると分かりますが、
「簡易的」とはいうものの
これはただ上下しているだけでジャンプに見えません。
同時に横移動させると不自然さがよく分かります。

ジャンプするなども参考になります。

不自然でも、「ゲームっぽいジャンプ」としてこのジャンプも充分ありかと思います。
ジャンプ後ボタン長押しで上昇量が変わる(初速で軌道が確定しない)ようなゲームでは厳密な放物線は不可能なので、
これに近いジャンプをしているのではないでしょうか。
ファミコンの「スーパーマリオブラザーズ」のマリオの場合「X方向が慣性と加速度で動いている＋上昇完了時の部分だけ小細工している」ので自然に見えるけど「Y方向の上昇下降はこれに近い動きをしている」という認識です。

inoking

KimiruHamiru wrote:
不自然でも、「ゲームっぽいジャンプ」としてこのジャンプも充分ありかと思います。
ジャンプ後ボタン長押しで上昇量が変わる(初速で軌道が確定しない)ようなゲームでは厳密な放物線は不可能なので、
これに近いジャンプをしているのではないでしょうか。
ファミコンの「スーパーマリオブラザーズ」のマリオの場合「X方向が慣性と加速度で動いている＋上昇完了時の部分だけ小細工している」ので自然に見えるけど「Y方向の上昇下降はこれに近い動きをしている」という認識です。

「滑らかに動かしたり　ジャンプさせたり」というお題だったのですが
よく見ると「滑らか」は「ジャンプ」にはかかってないのかも。ということに気づきました。

ただ、単純な横移動では三角の山形にしか動かないので変な感じはします。。

gagagagagagagaqqww

KimiruHamiru wrote:
不自然でも、「ゲームっぽいジャンプ」としてこのジャンプも充分ありかと思います。
ジャンプ後ボタン長押しで上昇量が変わる(初速で軌道が確定しない)ようなゲームでは厳密な放物線は不可能なので、
これに近いジャンプをしているのではないでしょうか。
ファミコンの「スーパーマリオブラザーズ」のマリオの場合「X方向が慣性と加速度で動いている＋上昇完了時の部分だけ小細工している」ので自然に見えるけど「Y方向の上昇下降はこれに近い動きをしている」という認識です。

まずこのジャンプでは段差（↓みたいなのです）を超えようとしたとき空中で停止してしまうのでは？

□□□□□□□□□□□□□□
□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□

kakurenbo

gagagagagagagaqqww wrote:
まずこのジャンプでは段差を超えようとしたとき空中で停止してしまうのでは？

その前に埋もれますね…

ARATAKU

左側から右にジャンプすると空中浮遊してしまい、
右側から左にジャンプするとめり込みますね。
どちらにしても、少しプログラムを改良すればすむとおもいます。
改良の仕方は、自分で考えるといいと思います。

KimiruHamiru

gagagagagagagaqqww wrote:
[まずこのジャンプでは段差（↓みたいなのです）を超えようとしたとき空中で停止してしまうのでは？
□□□□□□□□□□□□□□
□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□

それは、その通りです。

が、「質問者が何を求めているか」が最優先です。
「１種類のコード」で解決するかどうかは、「たまたま質問者の条件に合ったかどうか」という運任せです。

たとえば、こういうゲーム（？）で「最適なジャンプ」というのもあると思います。
https://scratch.mit.edu/projects/317236488/
段差
このゲームの場合、段差への配慮は意味がありません。対戦格闘のストリートファイターシリーズなど、普及したゲームでも「段差がない」あるいは「段差がない方が面白いという判断でデザインされた」ゲームはあります。
地面との接触判定
「地面との接触判定」は深い問題で、それを前提とすると、地面の厚さとか１フレーム当たりの移動量の想定とか横や上方向の接触時の対応とか、新たな問題となる要素がとても多くなるので、ジャンプについて質問するような段階の人なら「地面との接触判定」自体を避けるという選択も有力と考えます。
重力加速度
重力加速度に従うべきかどうかは「演出の問題（好みの問題）」であってコードの洗練度とか汎用性の問題とは独立した話です。スーパーマリオブラザーズは重力加速度に従いません。最大加速して右入れっぱなしの２Ｄマリオは「45度ぐらいの角度で一定速度で右下に落ちていく」のが当たり前でその前提でゲーム全体がデザインされているのではないでしょうか。

くり返しになりますが、ジャンプにはいろいろな種類があります。
どういうジャンプを選ぶかは、作り手の意図や技量によって決まります。
「Scratchで流行りのプラットフォーマータイプのジャンプ」以外ない、と考えるのはいろいろな可能性を捨てることになるので、もったいないです。

特定の状況に合わせてやり方を「選ぶ」のは、「改良」ではなく「最適化」とか言います。
変数を減らすことを優先するコーディングとか、並列処理を減らすことを優先するコーディングとか、
また、処理速度最大を目指すコーディングと読みやすさを最優先するコーディング
のような、両立が難しいからどっちを取るか選ぶ、というトレードオフが必要な選択もあります。

「ScratchWebサイトの文脈」に最適化することを考えた場合、「作り手や質問者が読みこなせないコード」に、私は価値を感じられないので、当事者がどこまでなら読みこなせそうなのか、なるべくそれを探ろうとしています。
「フォーラムで質問したけどぜんぜん理解できなかったのであきらめた」ケースもあるように感じているので、「ここだけはわかったけど、これはまだ早そうだ。いずれは挑戦したい」となるような、幅のある回答を模索しています。うまく行ってるかは別の問題ですが・・。

inoking

#152 について。全文引用します。

KimiruHamiru wrote:
inoking wrote:
KimiruHamiru wrote:
「メッセージ処理中は画面更新しない場合がある」
これは知らなかったのですが、もう少し詳しく教えてもらえませんか。
うわ突っ込まれちゃいましたね。表現が乱暴だったかもしれません。

私が想定してたのは
このスプライトがクリックされたとき
隠す
(30) 回繰り返す
[自分自身 v] のクローンを作る
end
クローンされたとき
[どこかの場所 v] へ行く
表示する
といったコードでは、30フレーム消費されるけど、
このスプライトがクリックされたとき
隠す
(30) 回繰り返す
[自分自身 v] のクローンを作る
end
[メッセージ1 v]を送って待つ
クローンされたとき
[メッセージ1 v]を受け取ったとき
[どこかの場所 v] へ行く
表示する
と書くとほぼ１フレームで処理が完了する、つまり、

「メッセージの処理中」は画面更新しない(各クローンが１フレーム消費して30フレーム１秒かかったり、一部のクローンだけ先に表示された状態になったりはしない)で遅延される
＝「メッセージの処理完了時」に（＝「メッセージ1を送って待つ」ブロックの実行完了時に）画面更新される

といった話でした。
scratchのフレームレートについて調べていた時にWebで見たと思うのですが、今探したらちょっと見つけられませんでした。

メッセージを受け取った側で複数フレームのアニメーションをしようとすると「経過が表示されず最終結果だけ表示されたり」で悩んだことがあったように思います。

参考：
https://scratch.mit.edu/projects/292731581/

以下は、私の独自研究によるものであることをあらかじめお断りしておきます。

これはメッセージがミソではありません。

まず、後者の「メッセージによる描画」についてです。
各クローンはマルチスレッド的に実行されます。
各クローンの処理内で描画込みのループが実行されると各クローン単位では待ちが発生しますが
同時に別クローンの処理が実行されるので複数クローンは並行動作をします。
「メッセージによる描画」では上記のような状況が発生しています。

前者の「ループによるクローン生成」の場合ですが、
ループによりクローンを生成する場合、描画込みのループ同様に各ループで待ちが発生しているようで
「30フレーム消費」というのはそれによるものです。
ループを使わないようにベタに展開すると待ちは発生しません。
ただし、親処理による全クローンの生成が終了してから各「クローンされたとき」が実行されるので注意が必要です。

サンプルを作ってみました。クローンの生成タイミング

過去の投稿で関係ありそうなものを挙げておきます。https://scratch.mit.edu/discuss/post/2876323/

Last edited by inoking (June 17, 2019 16:35:05)

inoking

ジャンプの件については
元の質問が具体性に欠ける（質問の仕方は #1 にも書かれています）ので何とも言いようがないですね。

Discuss Scratch