inoking

Scratch 3.0 への提案について話し合います。

2018/04/29:
Scratch 3.0 のリリースが間近になったため
scratch2.0の提案 で議論中の一覧をこちらにもってきました。
Scratch 3.0 への提案とは
Scratch 2.0 では(例えば以下のような事情で)実現がむずかしいと思われる提案のことです。
  • 互換性が保てない
  • 変更や影響の範囲が大きすぎる
このトピックは将来的には scratch2.0の提案 の Scratch 3.0 版のようなものになることを想定しています。

注意:
ここでの提案内容は、そのままでは Scratch チームには取り上げられません

正式に提案するには
英語のしかるべき場所(例えば Suggestions)で報告する必要があります。

このトピックの意義は
何かの機会に Scratch チームに伝えるための材料となるような提案内容を、日本語で煮詰めておく
ということです。

時々まとめを投稿してリスト化していきたいと考えています。
守ってほしいこと
★分かりやすくするためにブロックで表現するのもOKですが、説明もつけてください。
The Complete List of Rejected Suggestions(却下された提案)(日本語訳はコチラ)に出ている内容は提案不可です。
類似トピック
Scratch 3.0 に関する全般的な話は Scratch3.0について話し合う所
Scratch 2.0 への提案は scratch2.0の提案

inoking

「scratch2.0の提案」に以前ポストしたものです。既に英語モードで「レイヤー」という言葉が使われていたので「レイヤーグループ」にしました。

スクリプトの重なり順についてレイヤーグループの機能が欲しい。
現状ではスクリプトの重なり順を完全に制御するのが難しい。
例えば、動的に複数クローンが生成されては消えていくような場合。
完全に制御するには Scratch 内部の表示用制御リスト?の状態をエミュレートする必要があるが
大変だしアプリケーション側でやるようなことではない。

★用途の例
シューティングゲームで空中物、地上物、地面の重なりを再現

★実装例
デフォルトでレイヤーグループ1とし、
・必要に応じてレイヤーグループを追加できるようにするか
・あらかじめ決まった数のレイヤーグループを用意するか(5個程度で十分かと)

例えば以下のように、上位レイヤーグループに属する全スプライトは、下位レイヤーグループに属する全スプライトより前に表示される。
レイヤーグループ1
スプライト1
スプライト2

レイヤーグループ2
スプライト3
スプライト4


表示順序制御ブロック
前に出す
() 層下げる
はレイヤーグループの中でできるものとし、さらに以下のようなブロックを追加する。
レイヤーグループ()に移動 :: looks

inoking

転記させてもらいました。

CommandSlash017 wrote:

上と似ていますが、ペンの描画が最下段なのが気になります。ペンのレイヤーの制御機能を搭載して欲しいです。しかし2.0で実装するとグラフィックが変わってしまう可能性があるので3.0で実装するべきだと思います。

horamoon

Scratch3.0への提案の方がもし提案したときにSTにも余裕ができますし、いいですね。

inoking

以下の機能が欲しい。
キャプチャーする :: looks

★用途の例
実行時にコスチュームを作成
・ペンで描いて取り込む
・複数のスプライトを重ねた状態で取り込む

★実装例
スプライトの現在位置から一定範囲内の画像を
現在のコスチュームに取り込んで上書きする(保存はされない)。

取り込み範囲については検討が必要
例:四角形で指定、コスチュームの着色範囲で指定

★備考
保存できなければセキュリティー上も問題ない。

horamoon

でもキャプチャまでできちゃったらScratchじゃない気がする…。

inoking

horamoon wrote:

でもキャプチャまでできちゃったらScratchじゃない気がする…。
そうかも。。。
Scratch でやるのはどこまでなのか?ということは
3.0 でも大きくは変わらないでしょうが、少しずつは変わっていくものでもあるでしょう。
というわけで、この提案はちょっとグレーでしょうか。

apple502j

備考ですが、Scratch 3.0はHTML5でできているので、HTML5で実現が難しいものはほとんどが難しいです

inoking

switch 文(Select Case 文)の機能が欲しい。

ゲーム作りにおいては値によって一連の処理を切り替えることがしばしばあるが
もし <> なら 
でなければ
end
では階層が深くなってしまうため。

★備考
case 値の増減をユーザーインターフェース上どう実装するかが課題。

シフトキーを多用するようになると
Windows の場合、Shift キー5回押しで起動される「固定キー機能」が起動されてしまい混乱するかも
コピペで入っていたゴミを消しました。

CommandSlash017

inoking wrote:

switch 文(Select Case 文)の機能が欲しい。

ゲーム作りにおいては値によって一連の処理を切り替えることがしばしばあるが
もし <> なら 
でなければ
end
では階層が深くなってしまうため。

★備考
case 値の増減をユーザーインターフェース上どう実装するかが課題。

シフトキーを多用するようになると
Windows の場合、Shift キー5回押しで起動される「固定キー機能」が起動されてしまい混乱するかも
swith文の引数は文字列型が良いかと。
もし[]が[]であれば{}[]であれば{}[]であれば{}::control

horamoon

CommandSlash017 wrote:

swith文の引数は文字列型が良いかと。
もし[]が[]であれば{}[]であれば{}[]であれば{}::control
それだと
もし[文字列]が[]であれば{}[]であれば{}[]であれば{}::control
のようなことができてしまいますよ。

こちらのほうがいいと思います。
もし()が[]であれば{}[]であれば{}[]であれば{}::control

CommandSlash017

horamoon wrote:

あまり使わないかもしれませんが、
もし[文字列]が(A)であれば{}(B)であれば{}(C)であれば{}::control
のような使い方も考えることができます。

horamoon

CommandSlash017 wrote:

horamoon wrote:

あまり使わないかもしれませんが、
もし[文字列]が(A)であれば{}(B)であれば{}(C)であれば{}::control
のような使い方も考えることができます。
それはそのままでも問題ないと思います。

CommandSlash017

horamoon wrote:

CommandSlash017 wrote:

horamoon wrote:

あまり使わないかもしれませんが、
もし[文字列]が(A)であれば{}(B)であれば{}(C)であれば{}::control
のような使い方も考えることができます。
それはそのままでも問題ないと思います。
そのままとは?

horamoon

四角の枠にも変数は入れれます。

CommandSlash017

horamoon wrote:

四角の枠にも変数は入れれます。
そうですよ。ですから両方文字列型の引数にしたらどうかと言っているのです

inoking

horamoon さんが https://scratch.mit.edu/discuss/post/2738114/ で言っているのは最初の引数を数値型にしたら?ということですよね。

CommandSlash017 wrote:

swith文の引数は文字列型が良いかと。
もし[]が[]であれば{}[]であれば{}[]であれば{}::control
私もすべて文字列型(変数も はめ込み可能)が良いと思います。
すみません。型をあまり意識していませんでした。

inoking

プロジェクト編集系機能への要望まとめ

mochimochiking

inoking wrote:

switch 文(Select Case 文)の機能が欲しい。

ゲーム作りにおいては値によって一連の処理を切り替えることがしばしばあるが
もし <> なら 
でなければ
end
では階層が深くなってしまうため。

★備考
case 値の増減をユーザーインターフェース上どう実装するかが課題。

シフトキーを多用するようになると
Windows の場合、Shift キー5回押しで起動される「固定キー機能」が起動されてしまい混乱するかも
if~else if~else 文もほしい

inoking

mochimochiking wrote:

if~else if~else 文もほしい
もし <> なら 
でなければ
end
の入れ子でいいのではないですか?
そもそも、階層が深くなるような if~else はできるだけさけるべきです。
switch が決定的に違うのは(最初の引数で渡される)評価式が一つしかないということです。これは if~else では実現できません。