POP-COM wrote:

質問です。テラリアのメカニカルワームのような、画面外(スクラッチだと端)からプレイヤーの向きを向いて徐々にスピードアップして突進するプログラムをどうしても組めません。なんとかクローンに変数などを使ってやろうとしたのですが、どうしても再現できませんでした。もし、動かしながらマウスのポインターに向きを向け続けて移動できるプログラムを知っている方がいれば、教えて欲しいです

マウスの方向を向きながら突進する」動きを作るには、一気にマウスの方を向くのではなく、「今の向き」から「マウスの向き」へ、少しずつ角度を近づけるのがコツです。

1. 基本のアルゴリズム（スプライト本体・クローン共通）
以下のスクリプトを組むと、なめらかな旋回移動が実現できます。
作成する変数（このスプライトのみ）:

スピード : 現在の移動速度
旋回速度 : どれくらい急に曲がれるか（5〜10くらいがおすすめ）
スクリプトの流れ:

ずっと：
「マウスの方へ向ける」を使い、目標の角度を確認する。
（ここが重要）今の向きと目標の向きの差を計算し、「旋回速度」の分だけ今の向きを変える。
「スピード」を少しずつ大きくする。
「（スピード）歩動かす」
2. 具体的なブロックの組み方
「演算」ブロックを使って、以下のように記述するとスムーズです。

向きを ( (向き) + ( ( (マウスの方向) - (向き) ) / 旋回速度 ) ) 度にする
※ これにより、目標角度に近づくほど回転が緩やかになり、自然な曲線を描きます。

もし「メカニカルワーム」のように、体が連なって動くようにしたい場合は、以下の2つの方法を提案します。

リストを使う方法: 頭の座標（x, y）を常にリストに保存し、クローン（体）が数フレーム前の座標を追いかける方法。

シンプル版: 体のクローンに「1つ前のクローン（または頭）に向かって、一定の距離を保つ」というプログラムを書く方法。

長文失礼しました。

#12136
クローンがクローンを追いかける仕組みで作ってみました。
なんか、これじゃない気もしています。

https://scratch.mit.edu/projects/1275016767/

リストを使わず、時差でクローンの生成と削除を行う方法もあります。

POP-COM wrote:

質問です。テラリアのメカニカルワームのような、画面外(スクラッチだと端)からプレイヤーの向きを向いて徐々にスピードアップして突進するプログラムをどうしても組めません。なんとかクローンに変数などを使ってやろうとしたのですが、どうしても再現できませんでした。もし、動かしながらマウスのポインターに向きを向け続けて移動できるプログラムを知っている方がいれば、教えて欲しいです

abee wrote:

リストを使わず、時差でクローンの生成と削除を行う方法もあります。

その「時差でクローンを生成・削除する」というアイデア、いいですね！リストを使わないのであれば、「クローンの寿命」を変数で制御するのが一番スマートな再現方法だと思います。

具体的に、メカニカルワームっぽく見せるための設定のコツを整理しました。

1. クローン（体）側のプログラム

クローンには、それぞれ「何秒で消えるか」を覚えさせます。

クローンされたとき：

（体の長さ）秒待つ

このクローンを削除する

2. メカニカルワームらしく見せる調整のコツ

単に消えるだけだと「ただの線」に見えてしまうので、以下の工夫を加えると一気にクオリティが上がります。

節の間隔を保つ： 「自分自身のクローンを作る」の後に、少しだけ（0.1秒など）待つ時間を入れると、節と節の間に隙間ができてワームっぽくなります。

尻尾に向かって細くする： クローンの中で （（残り時間） * 〇〇） を使って、消える直前に向かって徐々に見た目を小さくしたり、透明度を上げたりすると、しっぽがシュッとしたリアルな見た目になります。

スピードとの連動： 頭が加速したときは、クローンの寿命（待つ秒数）を少し短くしてあげると、体が伸びきらずに自然な長さをキープできます。

注意点

この方法（時差消去）の場合、クローンがその場に止まってしまうので、もし「体も常にうねうね動かしたい」となったら、先ほどの旋回プログラムをクローン側にも少し弱めに適用してあげると良いですよ！

まずはこの「寿命方式」で、理想の長さになるか試してみてください！

長文失礼しました！

POP-COM wrote:

あれから色々進みました。(まだ全て理解はできていませんが)おそらくこちらの方が軽いのでこのプログラムと組み合わせたいのですが、変数の変更、仕組みなどがよく理解できていません。

POP-COM wrote:

POP-COM wrote:

カードゲームを作りたいなと考えているのですが、1つのスプライトでカードの種類を分ける(よく他のスクラッチャーさんがやってるところを見ます)には、変数かリスト変数どちらの方がメリットがあるのでしょうか。複数のデータを整理するリスト変数は一見便利に見えるので、どうすればいいのか迷います。
https://scratch.mit.edu/projects/1267155914
テスト用プロジェクトです。(まだブロック並べただけですが…)

この質問の続きです。ロジックはおおいた理解できました。…のですが、制御のプログラムを一つにまとめた方が軽くなるのかどうかわからないので、教えて欲しいです。

結論から言うと、「制御のプログラム（ループなど）は、可能な限り一つ（または少数）にまとめた方が動作は軽くなり、バグも減りやすくなります。

なぜまとめた方が良いのか、その理由とメリットを整理して解説します。

1. なぜ「まとめる」と軽くなるのか

Scratchの裏側では、プログラムは「上から順番に」実行されています。

バラバラの場合： 「ずっと」ループが10個あると、Scratchは1回画面を更新するごとに「ループAの処理→ループBの処理→…ループJの処理」と10回分のチェックを繰り返します。これが増えると処理の待ち時間が発生し、カクつき（ラグ）の原因になります。

まとめた場合： 「ずっと」の中に条件分岐（もし〜なら）を並べて1つにまとめると、コンピュータがチェックする回数が最小限で済み、効率的に処理が進みます。

2. 「リスト」と「まとめた制御」の相性が良い理由

前回の質問で「リスト」を使うメリットに触れましたが、制御をまとめる際にもリストは非常に強力です。

例えば、100枚のカードを1枚ずつ個別に制御するのは大変ですが、リストに「1番目のカードは場にある」「2番目は手札にある」といったステータスを入れておけば、1つのループ（クローン側の共通処理）だけで、全てのカードの状態を一度に更新できるからです。

3. プログラムをまとめるメリット

実行順序が明確になる： バラバラのスクリプトだと「どのブロックが先に動くか」が予測しにくく、原因不明のバグが起きやすいです。1つにまとめると、上から順番に実行されるため、動作が安定します。

「クローン」の管理が楽： カードゲームでは1つのスプライトを大量にクローンしますが、クローンごとに重いループを持たせると、すぐに限界（300個制限）や動作の重さにぶつかります。親玉（本体）がリストを操作し、クローンはそれを見て動くだけ、という形にすると非常に軽くなります。

4. 具体的な構成案

おすすめは、以下のように役割を分ける構成です。

管理用スクリプト（1つ）： リストの中身（HP、攻撃力、場所など）を計算して書き換える専用の場所。

表示用スクリプト（クローン共通）： 「もし自分の番号のリストが『手札』なら、この座標へ移動する」という、見た目を変えるだけのシンプルな処理。

アドバイス：プロジェクトの整理

テストプロジェクトを見ましたが、まだブロックを並べた段階とのことですので、今のうちに**「このリストのn番目は、n番目のクローンの情報を表す」**というルールを決めておくと、後から制御を一本化するのが非常にスムーズになります。

まとめ： 「制御を一つにまとめる」のは、Scratchで本格的なゲーム（特にカードゲームのようなデータ量が多いもの）を作る上での「必勝法」に近いテクニックです。最初は少し難しく感じるかもしれませんが、後々「作ってよかった」と思えるはずですよ！応援しています。

※だいぶ前の質問を長文で返してしまいました。。。申し訳ございません。

haru2579 wrote:

結論から言うと、「制御のプログラム（ループなど）は、可能な限り一つ（または少数）にまとめた方が動作は軽くなり、バグも減りやすくなります。

なぜまとめた方が良いのか、その理由とメリットを整理して解説します。

1. なぜ「まとめる」と軽くなるのか

Scratchの裏側では、プログラムは「上から順番に」実行されています。

バラバラの場合： 「ずっと」ループが10個あると、Scratchは1回画面を更新するごとに「ループAの処理→ループBの処理→…ループJの処理」と10回分のチェックを繰り返します。これが増えると処理の待ち時間が発生し、カクつき（ラグ）の原因になります。

まとめた場合： 「ずっと」の中に条件分岐（もし〜なら）を並べて1つにまとめると、コンピュータがチェックする回数が最小限で済み、効率的に処理が進みます。

一部誤解？が含まれているようなので補足しておきます。

各ループの待ち時間に別のループを実行するだけなので、ループの数自体が重さにつながることは実質ありません。
また、条件チェックをまとめようが各スクリプトに分散させようが、
1フレーム内ですべてチェックしないといけないことに変わりはなく、これも重さにはほとんど影響しません。

むしろ、スクリプト/クローン間の待ち合わせや競合といったアルゴリズム的な側面が、重さには劇的に影響します。
ペンプログラムなどでは顕著です。
処理をまとめると軽くなると感じられるのは、結果的にこのアルゴリズム的な側面も改善されるためと考えたほうがよいでしょう。

つまり、問題はループの数ではなく、
「制御のプログラム（ループなど）は、可能な限り一つ（または少数）にまとめた方が動作は軽くなる」とは必ずしも言えません。

むやみに分散させないほうがいいですが、
各スクリプトやクローンで処理が独立していたほうが可読性などは勝ります。

#12124および#12130の続きです

プロフィールにてコメントを頂いたので
プロジェクトURLを確認いたしました

ベクターは全て理解できるほど詳しいわけではないので
こうなる理由や仕組みはわからないのですが
以下のようにすると正しく表示されました
　
元の状態　　　　　　　　　　　より先端付近に点を打つ
　
元の点を消す　　　　　　　　　正常に表示される状態
一度上の画像のように編集してみてください

ベクターの曲線ツールはより先端に点がある方が
きれいに表示されることが多いように感じます
(あくまで「感じる」だけです)
私の予想になるのですが
拡大・縮小によって折り返しの見た目が違い
意図しない方向・位置に折り返しが発生するのだと思います

inoking wrote:

haru2579 wrote:

結論から言うと、「制御のプログラム（ループなど）は、可能な限り一つ（または少数）にまとめた方が動作は軽くなり、バグも減りやすくなります。

なぜまとめた方が良いのか、その理由とメリットを整理して解説します。

1. なぜ「まとめる」と軽くなるのか

Scratchの裏側では、プログラムは「上から順番に」実行されています。

バラバラの場合： 「ずっと」ループが10個あると、Scratchは1回画面を更新するごとに「ループAの処理→ループBの処理→…ループJの処理」と10回分のチェックを繰り返します。これが増えると処理の待ち時間が発生し、カクつき（ラグ）の原因になります。

まとめた場合： 「ずっと」の中に条件分岐（もし〜なら）を並べて1つにまとめると、コンピュータがチェックする回数が最小限で済み、効率的に処理が進みます。

一部誤解？が含まれているようなので補足しておきます。

各ループの待ち時間に別のループを実行するだけなので、ループの数自体が重さにつながることは実質ありません。
また、条件チェックをまとめようが各スクリプトに分散させようが、
1フレーム内ですべてチェックしないといけないことに変わりはなく、これも重さにはほとんど影響しません。

むしろ、スクリプト/クローン間の待ち合わせや競合といったアルゴリズム的な側面が、重さには劇的に影響します。
ペンプログラムなどでは顕著です。
処理をまとめると軽くなると感じられるのは、結果的にこのアルゴリズム的な側面も改善されるためと考えたほうがよいでしょう。

つまり、問題はループの数ではなく、
「制御のプログラム（ループなど）は、可能な限り一つ（または少数）にまとめた方が動作は軽くなる」とは必ずしも言えません。

むやみに分散させないほうがいいですが、
各スクリプトやクローンで処理が独立していたほうが可読性などは勝ります。

ありがとうございます。誤解していました。また学び直します。誤解を招き申し訳ございません。

著作権ジャンルだったため削除
→新・著作権について話し合うトピックに改めてポストしました。

#12153

制作お疲れ様です！おそらく、「大暴れ」の原因は、画面外処理と減速の計算が干渉しているか、クローン同士の座標参照がループしている可能性が高いです。

チェックポイント

変数の一本化: 速度の計算と画面外の座標計算を、別々のスクリプトではなく1つの「ずっと」の中にまとめていますか？

リストの更新: 追いかける相手の座標をリストから取る際、自分自身の番号を追いかけていませんか？

計算順序: 「移動 → 座標更新 → 摩擦（減速）」の順で処理すると安定します。

もしよければ、どのあたりで動きがおかしくなるか（速度が無限に上がる、ガタガタ震える等）を教えてもらえれば、ピンポイントで修正案を考えますよ！

「大暴れして吹っ飛ぶ」のは、クローンを使った多関節の動き（ワーム系）ではよくある現象です。

原因が「自分自身の番号を追いかけていたこと」であれば、そこを直すだけでかなり改善されます。さらに「ガタガタ震える」のを防いで「ヌルヌル」動かすためのポイントをまとめました。

追いかける対象の指定 クローンのIDを i 番としたとき、リストの i-1 番目（一つ前のパーツ）を参照するようにします。1番目のクローン（頭）だけは、マウスやプレイヤーを追いかけるように分岐させるとスムーズです。

震えを止める「遊び」の設定 目標との距離が近すぎるときに移動させると、座標を微細に行き来して震えが発生します。「もし 距離 > 1 なら移動する」という条件を入れるだけで解決します。

計算の順序 「移動 → 座標更新 → 摩擦（減速）」を一つのループにまとめると安定します。

・加速：速度に (目標座標 - 自分座標) * 0.1 を足す ・摩擦：速度に 0.8 などを掛けて減らす ・座標更新：実際の座標変数に 速度 を足す

注意点 速度の変数（vx, vy）が「このスプライトのみ」で作られているか確認してみてください。ここが「すべてのスプライト用」になっていると、全員で一つの速度を奪い合って爆発の原因になります。

うまくヌルヌル動くよう応援しています！

POP-COM wrote:

ありがとうございます。
ワーム君はガタガタ震えます。(というか吹っ飛びます)
x、yなどの軸計算はリスト表に入れて誤差が起きないようにしていましたが「ずっと」に確かにまとめていましたし、自分自身の番号も追いかけていました。少しいじってみます

#12153
作ったプロジェクトのプログラムを確認できると具体的に原因を分析できると思いますので、一度共有していただけませんか？

#12158
まず、「クローンされた時」のハットブロック以降、「ずっと」内1行目のsinを用いた計算を

((スピード) * ([sin v] of (theta)::operators))

と修正すると良いでしょう。
定義「速度」についてですが、このプロジェクトは、リストXYに座標情報を保存し、それを編集したのち描画するという手法を用いているため、そのまま採用するのであれば、

go to x: (0) y: (0)

を用いたほうが良いです。(ここではリストXYのクローンナンバー+2番目をthetaとしました)。また、「クローンされたとき」の下流で行っているリストXYの値の書き換えを、定義「速度」内でX,Yの描画前に行うと前のクローンとの位置をうまく保てると思います。
暴れについては、タイマー変化のスピードが変数版だと早すぎることがあばれの要因となるので、変化量を1/30にするとうまく動作すると思います。また、「速度」の引数には20程度の値(100など高い値の場合は暴れの原因になる)を入れると良いと思います。

傾向が消えて、通知は一生消えないし、プロフィールの変更もできなくなりました。STが何か変えたりしているからこうなっているのでしょうか？
それとも、scratchがサービス終了するのでしょうか…？

傾向が消えて、通知は一生消えないし、プロフィールの変更もできなくなりました。STが何か変えたりしているからこうなっているのでしょうか？
それとも、scratchがサービス終了するのでしょうか…？

傾向が消えて、通知は一生消えないし、プロフィールの変更もできなくなりました。STが何か変えたりしているからこうなっているのでしょうか？
それとも、scratchがサービス終了するのでしょうか…？

サービス終了というのは確定といっていいほどないと思います。傾向が表示されない現象は過去に何回か起きています。今現在、スクラッチが重くなっていて、それの影響でバグが発生しているのではないでしょうか。

The Scratch Team is working hard to fix an issue with the Scratch website　って先程まで出てきました。これってなんですか..?

kurosio-ZP wrote:

#12123

<<(ユーザー名) = [名前]> = <online?::sensing>>

がtrueになる原因としては、そもそもonline?は使用している端末がネットワークに接続されているかを検出するブロックなので、
WEB上でやってれば大体trueを返します。
また、ユーザー名=名前は、自分の名前が入っていればユーザー名と合致してtrueを返します。よって、
true=trueとなり、結果trueを返します。
また、自分のユーザー名でないかつ、online?がfalseを返した場合、無条件でtrueを返します。
間違っていたら訂正お願いします。

追記:よって、ユーザーが今いるかなどのオンラインを判断する機能はないと考えられます。
出典:オンライン_(ブロック)

↑恐らく

<<> and <>>

を使えばいいと思いますが….

otoya12 wrote:

The Scratch Team is working hard to fix an issue with the Scratch website　って先程まで出てきました。これってなんですか..?

バグで4つも送られてる
「スクラッチチームは、スクラッチウェブサイトの問題を修正するために懸命に取り組んでいます」という意味です。
STがバグ修正してくれているようです。

mokun12 wrote:

otoya12 wrote:

The Scratch Team is working hard to fix an issue with the Scratch website　って先程まで出てきました。これってなんですか..?

バグで4つも送られてる
「スクラッチチームは、スクラッチウェブサイトの問題を修正するために懸命に取り組んでいます」という意味です。
STがバグ修正してくれているようです。

ありがとうございます。複数個送られているのはバグなのでお気になさらずに。