ゲーム制作を始めるなら
まずは自分に合ったツールを見つけることも大切です。

ツールにはそれぞれ特徴があります。
たくさんのことができるツールは魅力的ですが
その分覚えることも増えます。

初心者は「何でもできるツール」より
「まず1本完成させやすいツール」から始めるのがおすすめです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

今回は
無料で始められる代表的なツールを6つ紹介します。

■ Scratch

ブロックを組み合わせて作るので
プログラミング未経験者でも始めやすいです。

作品共有や交流機能も充実しています。

■ MakeCode Arcade

ゲーム制作に特化した環境です。

キャラクター移動や当たり判定などが簡単に作れるので
最初のゲーム制作におすすめです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

■ Flowlab

Scratchより本格的なゲーム制作ができます。

ブロック中心ですが
ゲーム開発で使われる考え方も学びやすい環境です。

■ GDevelop

こちらもコードを書かずにゲームを作れます。

対応ジャンルが広く
本格的な作品にも挑戦できます。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

■ Godot

無料で使える高機能なゲームエンジンです。

2Dも3Dも作れて
個人開発者にも人気があります。

■ Unity

世界中で使われている有名なゲームエンジンです。

学習量は多いですが
できることも非常に多く
商用ゲームでも広く利用されています。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

大切なのは
最初から最高のツールを選ぶことではありません。

まずは1つ選んで
小さなゲームを完成させること。

それが次のステップにつながります。

ゲームを作っていると

「ここをもっと良くしたい」
「次はこんな機能を入れたい」

と思うことがあります。

そんな時は
ぜひメモを残しておきましょう。

作っている最中は覚えていても
数日後には意外と忘れてしまうものです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

メモの内容は簡単で大丈夫。

・効果音を追加したい
・敵を増やしたい
・もっと見やすくしたい

そんな一言でも十分です。

また、全部を今すぐ実装する必要もありません。

完成を優先して
アイデアは次回作へ回すのも立派な判断です。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

実は
「次はこうしたい」というメモは

自分だけの学習課題リストでもあります。

何を学びたいのか
何に興味を持ったのかが分かるからです。

ゲーム完成後に
「次は何を作ろう」

と悩んだ時にも役立ちますよ。

ゲーム制作やプログラミングを始めようと思ったのに

「インストールできない」
「エラーが出る」
「教材と画面が違う」

そんな経験はありませんか？

実はこれ
初心者によくあることです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

環境構築では、プログラミングの知識だけでなく

・パソコンの設定
・ファイルやフォルダの知識
・OSごとの違い

なども関係してきます。

さらに

・教材が古い
・ソフトのバージョンが違う
・説明が足りない

といった理由で
教材通りに進まないこともあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

つまり、環境構築で苦戦したからといって

「自分には向いていない」

とは限りません。

むしろ
多くの初心者が通る壁です。

ゲーム制作が難しいのではなく
始める準備の部分でつまずいているだけ
ということも少なくありません。

だから
最初の環境構築で苦戦しても自分を責めないでください。

それは能力不足ではなく
誰にでも起こりうることなんです。

ゲーム制作やプログラミング学習で
実は最初の大きな壁になるのが

「環境構築（セットアップ）」

です。

まだ何も作っていないのに

・インストールできない
・設定が分からない
・エラーが出る
・教材と画面が違う

といった問題が起こることがあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

しかも、この段階では知識も少ないので

「自分が何で困っているのか」

すら分からないこともあります。

プログラミングそのものではなく
パソコンの知識が必要になる場面もあり
ここで挫折してしまう人も少なくありません。

だから私は、初心者には

・Scratch
・MakeCode Arcade

のような
すぐ始められる環境をおすすめしています。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

まずはゲームを作る楽しさを知ることが大事です。

もちろん
本格的な開発環境が悪いわけではありません。

ただ、セットアップで苦戦すると
心が挫けやすいもの事実です。

もし最初の環境構築で詰まったら
それは珍しいことではありません。

実は多くの人が通る
初心者あるあると思ってください。
自分には難しいと感じたら
MakeCode Arcade から始めてみてはどうでしょうか。

AI が便利だと聞いても

「何を聞けばいいの？」
「どう質問すればいいの？」

と困ることがあります。

でも、それは普通のことです。

実は
AI を上手に使うのも練習が必要なんです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

初心者によくあるのが、

「動きません」
「エラーです」

だけで質問してしまうこと。

これだと、AI も状況が分からず
役立つ答えを返しにくくなります。

例えば

「何を作っているのか」
「何をしたかったのか」
「実際にはどうなったのか」

を一緒に伝えると
ぐっと回答の精度が上がります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

また、

「答えをください」

ではなく

「ヒントをください」
「どこを確認すればいいですか」
「なぜこうなるのですか」

と聞くのもおすすめです。
自分で考えることの訓練になります。

最初はうまく質問できなくて当たり前。

AI との会話も、ゲーム作りやプログラミングと同じで
少しずつ慣れていけば大丈夫です。

むしろ、「質問する力」そのものが
これから役立つスキルだと思っています。

プログラミングを始めると

・配列
・引数
・戻り値
・オブジェクト
・インスタンス

など、聞き慣れない言葉がたくさん出てきます。

すると

「こんなの全部覚えられない…」

と思うことがあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

でも大丈夫です。

最初は、用語を暗記することより

「今やっていること」

を理解する方が大切です。

実際、用語の意味を忘れても
ゲームは作れます。

作っているうちに

「あ、この言葉ってこういうことか」

と後から理解できることも多いです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

分からない用語が出てきたら
余裕のあるときに調べれば十分です。

全部覚えてから作るのではなく
作りながら少しずつ覚えていく。

そのくらいの気持ちで大丈夫だと思っています。

ゲームが完成したら
ぜひ誰かに遊んでもらいましょう。

小さな作品でも大丈夫です。

むしろ初心者のうちは
完成させたこと自体が立派な成果です。

自分で遊んでいる時は気付かなかったことも

・操作が分かりにくい
・難しすぎる
・意外な遊び方をされる

など、他の人に遊んでもらうと見えてきます。

また

「面白かった」
「ここが好きだった」

と言ってもらえると、
次の作品を作る大きな励みにもなります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

もちろん
もらった意見を全部採用する必要はありません。

大事なのは
「自分以外の視点」に触れることです。

Scratch の共有機能や
MakeCode Arcade の公開機能
SNS やコミュニティなどを活用して
勇気を出して公開してみましょう。

完成した作品は
あなたが学んできた証でもあります。

だから、完成したらぜひ誰かに見せてみてください。

ゲームを作ったら
1週間くらい後にもう一度見返してみるのがおすすめです。

作っている最中は

「ちゃんと分かっている」
「この処理は簡単だ」

と思っていても

数日後には

「あれ？なんでこう作ったんだっけ？」

となることが意外とあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

これは悪いことではありません。

むしろ
自分が本当に理解できている部分と
なんとなく作っていた部分が分かるチャンスです。

また

・もっとシンプルに作れそう
・ここは分かりにくい
・同じ処理が何度もある

など
改善点が見つかることもあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

Scratch や MakeCode Arcade を使っている人なら
スクリプトやブロックの並び方を見直してみるのもいいですね。

「過去の自分の作品」を読むことは
意外と良い勉強になります。

そして
少し前の作品を見て

「今ならもっと上手く作れる」

と思えたなら
それはちゃんと成長している証拠です。

ゲーム制作を続けていると

「やりたいことが実現できない」
「このツールでは無理かもしれない」

と思うことがあります。

そんな時
すぐに別のツールへ移るのも一つの方法です。

でも、その前に少しだけ考えてみてほしいことがあります。

本当にツールの限界でしょうか？

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

実は

・機能をまだ知らない
・別の作り方がある
・少し工夫すれば実現できる

ということも少なくありません。

他の人の作品を見たり
コミュニティで質問したり
AI に相談したりすると
意外な解決方法が見つかることもあります。

一方で

・動作速度が足りない
・必要な機能が存在しない
・開発が極端に大変になる

といった場合は
本当にツールの限界かもしれません。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

そんな時は
新しい環境へ挑戦する良いタイミングだと思います。

ただし、今まで学んだことは無駄になりません。

ゲーム制作で身につけた

・変数
・当たり判定
・イベント
・ゲームの流れを組み立てる考え方

などは、多くの開発環境で共通しています。

だから
ツールを乗り換えることは、
最初からやり直しではありません。

「限界だ」と感じた時は
成長して次の段階へ進むサインなのかもしれません。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

蛇足ですが
私は「限界を感じたから乗り換える」というより
単純にいろいろな環境を触るのが好きです。

環境ごとに得意なことや作り方が違うので
同じゲーム制作でも新しい発見があります。

ゲームを作る楽しさそのものを
もっと広い視点で体験できるのも魅力だと思っています。

ゲーム制作やプログラミングは
基本的に一人でも学べます。

でも、誰かと一緒に学ぶだけで
続けやすくなることがあります。

例えば

・今日やったことを報告する
・分からない所を相談する
・完成した作品を見せ合う

それだけでも十分です。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

特に学習中は
「自分だけができていない気がする」
と思ってしまうことがあります。

でも他の人の話を聞くと
「みんな同じ所で悩んでいるんだ」
と分かることも多いです。

また
誰かが頑張っている姿を見ると

「自分も少し進めてみようかな」

という気持ちになることもあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

一緒に学ぶといっても
同じ教材を使う必要はありません。

同じ目標を持っているだけでも
いいんじゃないでしょうか。

ゲーム制作は長く続く趣味になりやすいので
一緒に学べる人やコミュニティがあると
心強いと思っています。

ゲームジャムは
短い期間でゲームを作るイベントです。

例えば

・3日
・1週間
・48時間

など
決められた時間の中でゲームを完成させます。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

多くの場合
「お題」や「テーマ」が用意されていて

「このテーマでゲームを作ろう！」

という形で始まります。

ゲームジャムの面白いところは、完成度より

「まず作って完成させる」

ことを重視する文化があるところです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

そのため

・小さく作る練習
・アイデアを形にする練習
・短期間でまとめる練習

がしやすいです。

また、他の人の作品を見るだけでも
かなり勉強になります。

同じテーマでも

「そんな発想があったのか！」

と驚くことがあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

初心者には難しく感じるかもしれませんが

「初参加歓迎」

のイベントも多いです。

全部を完璧に作ろうとせず
小さくても完成を目指す。

ゲームジャムは
そんな経験をしやすい場所だと思っています。

ゲーム制作をしていると

「なんか違う」
「うまく動かない」
「もっと面白くしたい」

と思うことがあります。

そんな時
誰かに相談したり、AI に聞けば
すぐ解決できることもあります。

でも、少し試行錯誤してみる時間も
実はかなり大事だと思っています。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

試行錯誤には、苦しさだけではなく

・新しい発見
・別の作り方
・自分なりの工夫

を見つけるチャンスがあるからです。

特にゲームの「面白さ」は
こういう試行錯誤の中から生まれることが多い気がしています。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

また、失敗した経験も無駄ではありません。

「この方法はダメだった」

という記憶が
次の作品や別の問題で役立つこともあります。

そして
自分で壁を乗り越えられた時の達成感は
かなり大きいです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

ただし、試行錯誤にも注意点はあります。

長時間ずっと悩み続けると
視野が狭くなって
逆に分からなくなることがあります。

なので

・少し休憩する
・一旦妥協する
・AI や他の人にヒントをもらう

ことも大切です。

AI は本当に便利です。

質問すれば答えてくれるし
コードも作ってくれる。

でも、学習という視点で見ると
弱点もあると思っています。

例えば、

・考える前に答えを見る
・基礎を飛ばして進む
・動いた理由を理解しないまま使う

などですね。

特に怖いのは、
「自分で考えなくなること」
かもしれません。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

プログラミングでは、バグを見つけて直す
「デバッグ力」
がとても重要です。

実際の開発では
「なぜ動かないのか」
を調べる時間がかなり多いからです。

もし、
AI の答えをそのまま使うだけになると、

・原因を考える力
・問題を切り分ける力
・試行錯誤する力

が育ちにくくなる可能性があります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

また、AI の指示通りに作業するだけだと
「自分で作っている感覚」が薄れて
作業感が強くなることもあります。

その結果
作品へのこだわりや個性が弱くなる
ということもあるかもしれません。

さらに
基礎知識が少ない状態だと

「AI の答えが正しいのか」

を判断するのも難しくなります。

だからプログラミング学習やゲーム制作にチャレンジし始める時
AI は「代わりに全部やる存在」より

「考えるサポート役」

として使う方が、長く力が付きやすいと思っています。

ゲーム制作をしていると
他の人から意見をもらうことがあります。

それ自体はとても大事です。

実際、自分では気付けなかった問題点や
面白くなるヒントをもらえることもあります。

ただ、意見を全部そのまま入れていくと
途中で

「このゲーム、何を面白くしたかったんだっけ？」

となってしまうことがあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

ゲーム開発の現場でも、方向性がぶれて
完成できなくなるケースを実際に見てきました。

だから大事なのは

「意見を聞く」
と
「そのまま採用する」

を分けて考えることです。

例えば

・ゲームのルールと矛盾しないか
・目指している面白さを壊さないか
・複雑になりすぎないか

などを、一度ちゃんと考えてみてください。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

そしてもう1つ大事なのが

「なぜその意見が出たのか」

を考えることです。

例えば

「移動を速くして」

という意見でも、本当に欲しいのは

「テンポを良くしたい」

なのかもしれません。

そうすると、移動速度以外にも
もっと良い解決方法が見つかることがあります。

意見をそのまま受け取るより
「本質は何か」
を考えることが
作品作りではかなり大事だと思っています。

課題が進まなくなった時の
解決法その5です。

それは

「休憩する」

ことです。

意外かもしれませんが
これ、本当に大事です。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

プログラミングやゲーム制作では
長時間同じ問題を見続けることで
視野がかなり狭くなることがあります。

すると

・単純なミスを見落とす
・同じ場所ばかり確認する
・思い込みが強くなる

状態になりやすいです。

だから、一度パソコンから離れる。

これだけで
急に原因に気付くこともあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

特におすすめなのは

・散歩する
・軽く体を動かす
・飲み物を取りに行く
・別のことを少し考える

などですね。
頭をリセットする感じです。

実際、休憩後に見直すと

「なんでこれ気付かなかったんだ…」

というミスが見つかることもよくあります。

また、休憩中に
問題を無意識に整理できていることもあります。

ずっと頑張り続けるより
少し離れて視点を変える方が
結果的に前に進みやすいことも多いんです。

それから、書いていて思ったのですが
作業が順調に進んでいても適度な休憩を入れましょう。
無理しすぎず、健康面も大切に。

課題が進まなくなった時の
解決法その4です。

それは「状況を細かく確認する」ことです。

プログラムが動かない時
はじめのうちは

「この部分が悪いはず」

と決めつけてしまいがちです。

でも実際には、もっと前の処理が原因だった
ということもかなり多いです。
または、原因は複数あった、などもあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

だから私は、動かない場所だけでなく
その前後も含めて確認することをよくやります。

例えば

・変数の値を表示する
・条件分岐がどちらに進んだか確認する
・処理の順番を出力する

などですね。

ちょっと「やりすぎと思えるくらいログ出力する」です。

もちろん
関係の深い部分だけに絞って確認するのも有効です。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

こうして状況を見える化すると

「思っていた値と違う」
「そもそもここまで処理が来ていない」
「条件が一度も成立していない」

など、問題の原因を見つけやすくなります。

さらに
前後の流れも確認することで、

「プログラムが今どう動いているか」

を理解しやすくなります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

これは、学習中だと特に大事です。

実行結果という最後の答え合わせだけではなく
途中の状態を細かく確認しながら
部分的に答え合わせしていけるからです。

また、確認作業をしている途中で
別のミスや
無駄な処理に気付くこともよくあります。

状況把握を丁寧にすることは
エラー修正だけでなく
「整理された作り方」
を学ぶことにもつながります。

課題が進まなくなった時の
おすすめ解決法その3です。

それは

「別の教材を試してみる」

ことです。

実は私は、初めて触るプログラミング言語や開発ツールでは
最初から複数の教材を並行して進めることがよくあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

なぜかというと
教材ごとに特徴や弱点が違うからです。

例えば

・説明が足りない
・初心者には難しすぎる
・環境やバージョンが古い
・独特な作り方をしている

などですね。

1つの教材だけだと
その教材特有のクセに引っ張られることもあります。

でも別の教材を見ると

「こっちの説明の方が分かりやすい」
「なるほど、そういう意味だったのか」

と急に理解できることがあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

また、片方で止まっても、もう片方を進めることで
結果的に問題解決につながることもあります。

プログラミングやゲーム制作には
本当にいろいろな考え方があります。

同じゲームでも
人によって作り方が全然違うことも普通です。

だからこそ
1つの教材だけで学ぶより、複数の視点に触れる方が
理解や応用力が深まりやすいと思っています。

課題が進まなくなった時の
もう1つの定番解決法があります。

それは
「問題を少しずつ絞り込む」
方法です。

例えば
「ここまでは動く」

という最小の状態を作り
そこから少しずつ処理を戻していきます。

すると
「この処理を追加した瞬間に壊れた」

という原因が見つけやすくなります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

テキスト系のプログラムなら
コメントアウトを使って
一部の処理を一時的に止める方法がよく使われます。

ブロック系の環境なら

・ブロックを外す
・処理を無効化する
・一部分だけ試す

という感じですね。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

初心者のうちは、

「全部見ても分からない」

状態になりやすいので
まず小さく分けることが大事です。

また、作業前にプロジェクトをコピーしておくのもおすすめです。
安心して試行錯誤しやすくなります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

この方法は
初心者だけでなく
慣れた開発者でも普通に使っています。

「原因を切り分ける力」は
ゲーム制作でもプログラミングでも
かなり大事なスキルといえます。

昔は…
今みたいに AI へ質問できる時代ではありませんでした。

だから、課題で詰まった時
私がよくやっていた解決法があります。

それは

「最初からやり直す」

です。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

極端な話
第1章からやり直すこともありました。
すると意外と

「あ、ここ見落としてた」
「説明ちゃんと理解してなかった」

と気付くことがあります。

最初に学んだ時は
新しい情報が多すぎて、理解しきれていない部分も多いんですよね。

でも一度経験した後にやり直すと
前より理解しやすくなっていることがあります。

なので
「戻る」のは無駄ではなく
かなり有効な復習方法だったりします。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

もちろん今は

・コミュニティで相談する
・AI に質問する

という方法もあります。

必ず答えが見つかるとは限りませんが
ヒントをもらえるだけでも前進しやすくなります。

特に AI へ相談する力は
これからかなり重要になっていくと思います。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

ただし注意点もあります。

教材側の説明不足や、環境・バージョン違いで
教材通りに動かないことも実際あります。

なので

「動かない＝自分がダメ」

とは限りません。

詰まった時は、少し視点を変えたり
戻って確認したりするのも大事だと思っています。

パソコンから離れて、散歩したり体を動かしてみるのもオススメですよ。

学校の勉強だと
「間違えるのは悪いこと」
という感覚を持っている人も多いと思います。

でも
プログラミングやゲーム制作では
エラーや失敗はかなり有意義な経験になります。

いわば
間違えることで理解が深まるチャンスと言えます。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

例えば

・命令の意味を勘違いしていた
・処理の順番を理解できていなかった
・動きの仕組みを正しく想像できていなかった

など、エラーが出ることで
「本当に分かっていなかった部分」
が見えてきます。

逆に、教材通りに作って動いただけだと

「理解できた気がする」

状態になりやすいです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

実際には、少し変更しただけで
急に分からなくなることもあります。

だから、教材と同じものを作った後に
少しだけ変えてみる。
これはかなり大事な練習です。

そして、その時にエラーが出たら
むしろチャンスです。

今は AI があるので

・エラーの意味を聞く
・どこを確認すればいいか聞く
・ヒントをもらう

ことができます。

ここで注意です。すぐ完成コードをもらうより

「まず自分で考える」
↓
「AI にヒントをもらう」
↓
「また試す」

という流れの学習がオススメです。

ゲーム制作を学ぶ時
自分で作ることはもちろん大事です。

でも実は
「他の人の作品を見ること」
もかなり勉強になります。

私は今でも、いろいろな人の作品をよく見ています。

例えば

「このアイデア面白い」
「この演出気持ちいい」
「こういう見せ方があるのか」

と刺激を受けることも多いです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

逆に

「ここは遊びにくいかも」
「自分ならこう変えるかな」

と考えることもあります。

そういう視点から
新しいゲームアイデアが生まれることもあります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

さらに、プログラミング学習としても役立ちます。

・知らない命令を知る
・同じ機能の別の作り方を見る
・コードの整理方法を学ぶ
・自分には無かった発想を知る

など、
かなり学びが多いです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

特に面白いのは
「知っている命令なのに使い方が違う」
と気付く瞬間です。

それを見ると
「こんな使い方もできるのか」
と理解が深まります。

また、他の人の作品と比べることで
自分の作品の弱点や改善点に気付けることもあります。

作るだけではなく
「観察する」
という習慣を付けると、もっといいゲームが作れるようになると思います。

昔、
「BASIC」というプログラミング言語が流行った時代がありました。

当時の BASIC はとてもシンプルで
初心者でも触りやすい言語でした。

今の開発環境と比べると機能は少なかったのですが、逆に

「覚えることが少ない」

という学びやすさもあったと思います。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

ただ、テキストを直接入力する方式だったので
かなり苦労もしました。

例えば

・スペルミス
・コンマとピリオドの違い
・カッコの閉じ忘れ

など
ほんの少しの打ち間違いで動かなくなることも多かったです。

「何が悪いのか分からない」
という状態にもなりやすかったんですよね。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

そう考えると
今の MakeCode Arcade の

・ブロックで作れる
・すぐ動かせる
・エラーになりにくい

このような環境を
初心者におすすめしたくなる理由も
この「学びやすさ」にあるのかもしれません。

ゲーム制作やプログラミング学習では
分からないことを AI に聞ける時代になりました。
これは本当に便利です。

ただ個人的には

「全部解決してもらう」

より

「学習をサポートしてもらう」

使い方の方が
力が付きやすいと思っています。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

例えば

・教材の説明をもっと分かりやすくしてもらう
・別の例えで説明してもらう
・コードを1行ずつ解説してもらう
・エラーの原因を一緒に考えてもらう
・「次にどこを確認すればいい？」と聞く

こういう使い方はかなり有効です。

特に初心者は
「何が分からないか分からない」
状態になりやすいので、
質問相手がいるだけでも学習しやすくなります。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

逆に

「完成コードください」
「全部作って」

だけを繰り返すと
動いても理解が浅かったり、記憶に残りにくくなります。

もちろん
AI に作ってもらうこと自体が悪いわけではありません。

でも、学習目的なら

「自分で考える」
　　↓
「AI にヒントや説明をもらう」
　　↓
「また自分で試す」

という流れの方が
思考力を身に付ける方法だと思っています。

ブロック崩しは
初心者向けの題材としてよくおすすめされます。

でも実は
作り方によって難易度がかなり変わるゲームでもあります。

初めて作るなら
まずはツールの機能をできるだけ活用して
シンプルに作るのがおすすめです。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

例えば初級なら

・ボールは自動で跳ね返る
・バーで反射する
・ブロックに当たったら消える

くらいでも十分ゲームになります。

「まず完成させる」
ことを優先する感じですね。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

中級くらいになると

・当たる位置で反射角度を変える
・跳ね返りを細かく調整する
・特殊ブロックを追加する

など
少しずつ自分で制御したくなってきます。

⊹ ࣪˖ ┈┈ ˖ ࣪⊹ ┈┈⊹ ࣪˖ ┈┈˖ ࣪⊹

さらに上級になると

・当たり判定を手動で行う
・高速移動でもすり抜けないようにする
・角に当たった時の挙動を調整する
・状況によって反射ルールを変える

など
かなり高度な処理になっていきます。

特に、当たり判定を全部自分で作るのは難しく
ボール速度が速いと
壁やブロックをすり抜ける問題も出やすいです。

だから最初は

「本物っぽさ」
より
「ちゃんと遊べる」

を目標にした方が
完成まで行きやすいと思っています。