if <> then 

  

else

end

set [ v] to [0]

if <> then
set [ v] to [1]
end

if <<not <>> and <(foo) = [0]>> then

end

#798 および、旧トピックの #3983, #4416, #4971 も読んでみてください。
このエッセイも読んでみてください。

tsumuri3 wrote:

JavaScriptの文字列.substr(自然数)機能を提案します。
ブロックにして

(() の()番目から番目から最後までの文字  ::#3fff3a

みたいな感じだと思います

文字列操作関数の提案はたまにありますが、
自作できる。というのがこれまでのこのトピックでの大体の見解です。

これらはすべて作品側で用意できます。難易度は高くありません（もちろん完全な Scratch 初心者は別です）。

文字列操作は練習問題にぴったりです。

2.8 AI画像生成
・様々なデメリットがある
・AIアシスタントは却下されていない

3.8 ショート形式のコンテンツ
・Scratchのプロジェクトは明確な実行時間を持たない
・Scratchは動画ベースではなく、「長さ」を定義できない

-popcorn_yummy- wrote:

作品と作品を通信できる変数などはどうでしょう
（例:作品Aの通信する変数を1にすると作品Bの通信する変数も1になる）

・他のプロジェクトとの変数共有
理由：#59

(join [] [])

(join ["ゴミ箱ボタン"　] ["ゴミ箱ボタン"　] ["ゴミ箱ボタン"　] ["ゴミ箱ボタン"　] "+ボタン")

(join (join [] []) (join[] []))

if <> then 
else
end

if <> then
else
※一つ上は"else"ではなく"else if<> "ゴミ箱ボタン""
else
end
※一つ上は" "ではなく"+ボタン"

<touching [ v] ?>
<touching color [#1b37da] ?>
when this sprite clicked

当たり判定を [矩形 v]にする

当たり判定を [有効化 v]

Zirconium_Tungstate wrote:

いくつかアイデアを思いついたのでまとめてみました。
アイデア1…

(join [] [])

など一部ブロックの可変長引数化
～略～

アイデア2…else-if

if <> then 
else
end

は既に存在するが、アイデア1の+ボタンの仕組みを利用し、
～略～
これもQOLの向上が目的。

アイデア3…変更可能なモード
Scratchでは当たり判定でピクセル判定を実装していて、それで描画時にGPUが使えずCPUで描画を行っているのがラグの一つの原因となっている。
モードを変更すると描画時にGPUが使えるようになる代わり、
～略～

署名で申し訳ないですが wrote:

Scratchを触ってこそ、本物の言語のすさまじい力を知る。

inoking wrote:

#1 に書いてある以下も読んでみてください。

#798 および、旧トピックの #3983, #4416, #4971 も読んでみてください。
このエッセイも読んでみてください。

Yukihisa2022 wrote:

3.8 ショート形式のコンテンツ
・Scratchのプロジェクトは明確な実行時間を持たない
・Scratchは動画ベースではなく、「長さ」を定義できない

Paddle2See wrote:

PIXEL_BY_PIXEL_ERROR wrote:

Scratch is a coding platform, not a video platform.

That's where I land as well.

inoking wrote:

「Scratch はコーディングプラットフォームであって、動画プラットフォームではない」
ということに ST メンバーも同意している
ということも補足として記載しておこうと思います。

3.8 ショート形式のコンテンツ
・Scratchは動画プラットフォームではない
・実行時間が不定であり、プロジェクトの明確な「長さ」を定義できない

inoking wrote:

Zirconium_Tungstate wrote:

いくつかアイデアを思いついたのでまとめてみました。
アイデア1…

(join [] [])

など一部ブロックの可変長引数化
～略～

アイデア2…else-if

if <> then 
else
end

は既に存在するが、アイデア1の+ボタンの仕組みを利用し、
～略～
これもQOLの向上が目的。

アイデア3…変更可能なモード
Scratchでは当たり判定でピクセル判定を実装していて、それで描画時にGPUが使えずCPUで描画を行っているのがラグの一つの原因となっている。
モードを変更すると描画時にGPUが使えるようになる代わり、
～略～

署名で申し訳ないですが wrote:

Scratchを触ってこそ、本物の言語のすさまじい力を知る。

#9048 から再掲します。

inoking wrote:

#1 に書いてある以下も読んでみてください。

#798 および、旧トピックの #3983, #4416, #4971 も読んでみてください。
このエッセイも読んでみてください。

また、「本物の言語」とありますが
そもそも Scratch はブロックプログラミングではあっても本格的な言語です。
学びやすさを両立しているだけです。

まず Scratch の理念を理解したうえで提案をお願いします。

そして、実務面でも
・GPU を使うと何でも高速化できるものではありません。
・「QOL」を繰り返していますが「QOL」とは一般的に「Quality of Life」のことです。
知識内容をよく確認するようお願いします。
他にも
代替可能性、互換性、ユーザーインターフェースの一貫性などなど
色々考慮すべき点はあります。


さらに、投稿と直接関係がないことで申し訳ないですが
新造アカウントではなく
本アカウントで投稿するほうが文責という点で信頼性が高くなります。

inoking wrote:

みなさんへ：
こちらを再掲しておきます。
元の英語のトピックは2015年のものなので現在とはちょっと事情が違うかもしれませんが、ほぼ通用するでしょう。

inoking wrote:

Scratch ブロックの考え方として
以下のような説明が英語の提案フォーラムにあります。
A guide to suggestions

Scratch doesn't always have to be super simple, and, for that matter, shouldn't be. For example, if you suggested a “physics” block, which made a sprite follow the laws of physics, this would probably be rejected. Why? It would certainly be useful! The problem is (beyond the difficulties in making such a block) that it makes Scratch too easy. It is kind of taking the “program” out of “Imagine, program, share”. We don't want to be able to make anything in five minutes; that ruins the point of programming, having fun, and putting effort into your projects. However, you can always feel free to make your own physics tutorial, and share it with the community, so that those who don't know how to program physics could learn to program physics.

↓ざっと訳
スクラッチはいつも超シンプルである必要はありません。
例えば、物理学の法則に従ったスプライトを作成した「物理学」ブロックを提案した場合、これはおそらく却下されます。
どうして？それは確かに便利でしょう。
問題は Scratch をあまりにも簡単にすることです。それは、「想像、プログラム、共有」から「プログラム」を取り去っているようなものです。
私たちは5分で何かを作れるようにすることを望んでいません。
それはプログラミングする、楽しい時間を費やす、作品に力を注いだりする、ということを損ないます。
しかし、あなたはいつでも自分の物理学チュートリアルを作成し、コミュニティと共有することができます。
それによって、物理学のプログラミムを知らない人が物理学のプログラムを学ぶことができます。

abee wrote:

#9054
この中のいくつかは、Scratchと同じScratch Blocksを使ったMakeCodeで採用されているものですね。
それなので、Scratchでも実現可能ですが、後方互換性などを考えて、あえてやっていないということだと思います。
また、「Scratchでは当たり判定でピクセル判定を実装していて、それで描画時にGPUが使えずCPUで描画を行っているのがラグの一つの原因となっている」の「描画時にGPUが使えず」の意味が良くわからなかったので、詳しく説明してもらえますか。矩形領域で当たり判定を行えば確かに速くなりますが、複雑な形状のコスチュームの場合は細かく矩形を分割する必要があります。また、現状でもプログラムで実装可能です。

Yukihisa2022 wrote:

#2の却下された提案について、原文が更新されたので、#2についても更新をお願いします。
(前回の更新)

約
また、こちらで提案されている内容も含めて更新をお願いします。

Yukihisa2022 wrote:

#9056

inoking wrote:

「Scratch はコーディングプラットフォームであって、動画プラットフォームではない」
ということに ST メンバーも同意している
ということも補足として記載しておこうと思います。

それは「Scratchは動画ベースではなく」で説明が足りていませんか？
改良するとしたら

3.8 ショート形式のコンテンツ
・Scratchは動画プラットフォームではない
・実行時間が不定であり、プロジェクトの明確な「長さ」を定義できない

のような形でしょうか。