Scratch2.0でゲームを作る場合の定石的なものをポストしていこうと思います。
（自分のための備忘録的な事も兼ねています）

よくあるキャラクターを動かして敵に当たったら的なゲームの場合。
ゲームキャラクターに絵はつきものですが、当たり判定などに絵そのものを使うと難易度の調整などが複雑になります。
この当たり判定もゲームバランスを取る上でかなり重要になるので、画面に出ているキャラクターとは別に「当たり判定用」のスプライトを作成し、当たり判定はそのスプライトで行うようにします。

サンプル

このサンプルでは、実際の当たり判定は猫の絵の大きさで取られていないのが分かると思います。

キャラクターがジャンプするタイプのゲームの場合は、重力と縦方向の移動量を使うと作りやすいです。
移動量はなにもしなくても「ずっと」ループの中で、毎回重力の値が加算されていきます。
この移動量をＹ座標に足していきます（Scratchは直交座標系なので重力の値がマイナスになります）。
こうすると擬似放物線を描く動きが作れます。
なにかのキーが押された時に、移動量にプラスの数値を入れるとジャンプします。

このままではキャラクターが画面の一番下まで行ってしまいますので、なにかとの衝突判定を行います。
これは色でもスプライトでもいいのですが、Ｙ座標を変更してその都度当たり判定を取るやりかただと、障害物ギリギリまで行くことが出来ません。

この場合は、「Ｙ座標を1（もしくは-1）づつ変える」を移動量だけ行います。
途中で当たり判定でぶつかっていた場合は、ひとつ前に座標に戻し、それ以降は座標の値は変えません。
これで障害物ぎりぎりまで寄ることが出来ます。

サンプル

このサンプルでは、カーソルキーの左右で移動し、カーソルキーの上でジャンプします。
カーソルキーの上を押している時間の長さでジャンプする高さが変わります。
なので、キーを離した時にジャンプします。

ゲームでもゲームじゃなくてもプログラムの見やすさは重要だと思う。

hota1024 wrote:

ゲームでもゲームじゃなくてもプログラムの見やすさは重要だと思う。

そうですね、1ヶ月後の自分が読んでも、コードが理解出来るような作りが理想ですね。

digitarhythm wrote:

hota1024 wrote:

ゲームでもゲームじゃなくてもプログラムの見やすさは重要だと思う。

そうですね、1ヶ月後の自分が読んでも、コードが理解出来るような作りが理想ですね。

「リーダブルコード」ですね
よりよいコードを書くためのシンプルで実践的なテクニック

hota1024 wrote:

digitarhythm wrote:

hota1024 wrote:

ゲームでもゲームじゃなくてもプログラムの見やすさは重要だと思う。

そうですね、1ヶ月後の自分が読んでも、コードが理解出来るような作りが理想ですね。

「リーダブルコード」ですね
よりよいコードを書くためのシンプルで実践的なテクニック

読みやすいコードにしておくと、リファクタリングをする時にも役に立ちます。

digitarhythm wrote:

hota1024 wrote:

digitarhythm wrote:

hota1024 wrote:

ゲームでもゲームじゃなくてもプログラムの見やすさは重要だと思う。

そうですね、1ヶ月後の自分が読んでも、コードが理解出来るような作りが理想ですね。

「リーダブルコード」ですね
よりよいコードを書くためのシンプルで実践的なテクニック

読みやすいコードにしておくと、リファクタリングをする時にも役に立ちます。

理解しやすいコードを書くのはどんなプログラミング言語にとっても重要ですね。
（話がちょっと変わってしまいましたね_(._.)_）

hota1024 wrote:

digitarhythm wrote:

hota1024 wrote:

digitarhythm wrote:

hota1024 wrote:

ゲームでもゲームじゃなくてもプログラムの見やすさは重要だと思う。

そうですね、1ヶ月後の自分が読んでも、コードが理解出来るような作りが理想ですね。

「リーダブルコード」ですね
よりよいコードを書くためのシンプルで実践的なテクニック

読みやすいコードにしておくと、リファクタリングをする時にも役に立ちます。

理解しやすいコードを書くのはどんなプログラミング言語にとっても重要ですね。
（話がちょっと変わってしまいましたね_(._.)_）

後々、リファクタリングする事を前提にするのであれば、最初はまず動くことが大事なので、正しく動く事を第一に作るのもありです。
私は最初のリファクタリングで無駄を削り、2回目のリファクタリングでアルゴリズムを最適化しています。
だいたいリファクタリングは2回行うと最適なコードになります。

digitarhythm wrote:

hota1024 wrote:

digitarhythm wrote:

hota1024 wrote:

digitarhythm wrote:

hota1024 wrote:

ゲームでもゲームじゃなくてもプログラムの見やすさは重要だと思う。

そうですね、1ヶ月後の自分が読んでも、コードが理解出来るような作りが理想ですね。

「リーダブルコード」ですね
よりよいコードを書くためのシンプルで実践的なテクニック

読みやすいコードにしておくと、リファクタリングをする時にも役に立ちます。

理解しやすいコードを書くのはどんなプログラミング言語にとっても重要ですね。
（話がちょっと変わってしまいましたね_(._.)_）

後々、リファクタリングする事を前提にするのであれば、最初はまず動くことが大事なので、正しく動く事を第一に作るのもありです。
私は最初のリファクタリングで無駄を削り、2回目のリファクタリングでアルゴリズムを最適化しています。
だいたいリファクタリングは2回行うと最適なコードになります。

無理に読みやすさ重視で作って「動かない！＿|￣|○ il||li」となるよりも、ちゃんと「書いたとおりに動いているか」を確認しながら僕はプログラムを書いています。そのあとからリファクタリングを行って読みやすいコードに整形しています。
（やり方はほぼ同じですね）
スクラッチでもこの考え方は使えますね。
リファクタリングも出来ますし、ただスクラッチの関数には「戻り値」がないので少し見にくく感じてしまうのがたまにきずです。
早くスクラッチに実装されないかな～（殴（引退宣言した人が何言ってんだ（笑）

Scratchの縛りを意識しながらコーディングする事は、他の言語を学ぶ上でもいい経験になりますね。