この動画は
電子書籍の絵本の作り方を説明しているものだけど、初学者がアドベンチャーゲームなどを作りたいと思ったときの参考になるかも

プロットを作りたいときや、ゲームに使う絵（素材）が欲しいときにこれなら簡単に作れる
ガッツリ作りたい人向けではないけど、やってみたいなーと思っている程度なら非常にいいと思う
以前、自分もアドベンチャーゲーム（ノベルゲーム）を作りたいと思ったことがあったけど、そのとき、絵（素材）を集めることが困難でやめてしまった
この動画の方法で絵を作成し、affinity で読み込んでそれぞれの絵をスライスすれば簡単に絵の利用ができると思う

「パズループ」というゲームの発案した時の流れを note に書きました。
有料マガジンですが、途中までは無料で読めます。
きっかけから案がまとまっていく流れが参考になると思います。
オリジナルゲームを考えるのは難しいです。いきなり結果を出そうとすると心が折れそうになることもあるので、試行錯誤を楽しんでください。

ブラウザで遊べるチェス変種「Q-Gambit」を作っています。開発にはCodexを使っています。

駒を動かす小さな練習に分けたチュートリアルがあります。添付は現行版の第4章を、操作前に撮ったものです。

この場面では、a7とh5の黒駒がどちらも「ルークかクイーン」です。h5の駒を斜めにf3へ動かして白のナイトを取ると、2つの変化が起きます。

・それまで直線に動いた駒が斜めにも動くため、クイーンに確定します。

・各色の元のクイーンは1体なので、a7は動かさずにルークに確定します。

この練習では駒を3つに絞り、盤面と説明を並べています。伝える必要があるのは、動かした駒の変化だけでなく、離れた駒とのつながりです。一度の操作で2か所が変わるので、どちらに注目すればよいかも大事になります。

こうした連鎖する変化を教えるとき、操作した駒と離れた駒の説明は、どの順番で見せると追いやすいでしょうか？

現行版：https://q-gambit.com/

ホームの「遊び方」から試せます。チュートリアルとCPU練習は無料で、アカウントやダウンロードは不要です。初回は利用規約・プライバシーの確認があります。

撮影環境では3Dを表示できず、2D表示に切り替わっています。

Unityで、相手への質問を自分の言葉で入力できる短い尋問ゲームを一人で作りました。「The Interview」という無料のWindowsゲームです。

宇宙ステーションの面接官になり、目の前のMara Veyの話と書類にある8つの情報を照合します。最後に、入場を認めるか拘束するかを自分で決めます。文字入力のほか、Vキーを押してマイクで質問することもできます。

工夫したのは、会話に終わりと判断を作ることです。自由に質問できても、回数は18問まで。「質問する」「圧力をかける」「非難する」で相手の落ち着きが変わり、圧力をかけすぎると回答を拒否することがあります。

返事はQwen3というAIモデルがPC上で生成しますが、質問回数やキャラクターの状態はゲームのコードで管理します。AIにルールを変えさせず、プレイヤーに最後の判断を残す、という分担です。音声認識はWhisper、声の生成はQwen3-TTSです。

難しいのは、返事が書類と矛盾したときです。人物が嘘をついているように見えるのか、単に生成が失敗したように見えるのか。この違いが遊びやすさに直結します。試した方には、日本語の返事の自然さと、18問で判断に必要な情報を集められるかを聞きたいです。待ち時間が気になる場面も教えてもらえると助かります。

ダウンロード：https://merrymaker14.itch.io/the-interview

Windows 64-bit、無料です。ゲーム本体は約1.5GB、初回に標準の会話モデルを約1.7GBダウンロードします。音声機能には追加のモデルが必要です。最初のダウンロード後はPC内で生成でき、クラウドAIの利用料やAPIキーは不要です。速度はPCによって変わり、返事に事実の間違いや矛盾が出ることがあります。

日本語を含む10言語に対応しています。ゲームは私が開発している有料Unityプラグイン「Offline AI NPC」を使っていますが、遊ぶためにプラグインを購入する必要はありません。

読んでいただきありがとうございます。初心者の方にも、会話の自由さとゲーム側のルールを分ける例として伝わればうれしいです。

あまりにも間が空きすぎていて独創的な発想もなければ制作を続けられるほどの気力もない アニメはなんとか作れるのに何故なのだろうか

こんにちは。

現在、学生プロジェクトの一環として、個人開発者やインディーゲーム開発者が、ゲーム制作中に必要なアセットをどのように用意しているのかについて調査しています。

特に、自分では作れない、または制作に時間がかかる2D・3Dアセットなどを、普段どのように入手・制作しているのか、どのような点に困っているのかを知りたいと考えています。

また、ローカル環境で動作する生成AIやオープンソースのツールが、実際のゲーム開発で役に立つ可能性があるのかについても調査しています。

生成AIを使っている方だけでなく、使ったことがない方、使いたくない方、以前使ってやめた方の意見もとても重要です。

アンケートは約4分で回答できます。

https://docs.google.com/forms/d/e/1FAIpQLScqkfLslaEA5hmfvKDCZxnlng9F3a8Zb1pWyR2yqsC-GpUYUA/viewform?usp=dialog

アンケートは英語ですが、できるだけ簡単な内容になっています。

この調査の目的は、最初から「こういうツールが必要だ」と決めつけることではなく、実際の開発者がどのような問題を抱えているのか、そして本当に需要があるのかを理解することです。

個人開発者、学生、小規模チーム、ゲームジャム参加者など、幅広い方から回答をいただけると嬉しいです。

ご協力いただけると大変助かります。
よろしくお願いします！

ゲーム作りのアドバイスばかり投稿してもつまらないので、ミニゲームを作って見せていこうと思う。

今回のゲームは、下のリンクから遊べる。
スマホなら画面のコントローラから。PCはキーボードの矢印キーと Z キーまたは SPACE キーで操作。

逆さ操作でプレイするミニゲーム

ゲーム制作を始めると
「デバッグ」という言葉をよく見かけます。

デバッグとは簡単に言えば

「うまく動かない原因を探して、直す作業」

のことです。

例えば

・ボタンを押しても反応しない
・敵に触れていないのにミスになる
・取ったはずのアイテムが消えない
・得点が二重に増えてしまう

こうした問題を「バグ」と呼びます。

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

ただし
デバッグは適当にコードを書き換えることではありません。

まず

「どんな時に問題が起きるのか」

を確認します。

毎回起きるのか。
特定の操作をした時だけなのか。
どこまでは正しく動いているのか。

そして
処理の途中に数字や文字を表示したり
怪しい部分を一時的に止めたりして
原因の場所を少しずつ絞っていきます。

直した後は
同じ操作をもう一度試して
本当に問題がなくなったかも確認します。

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

ゲーム制作では
一度もバグを出さずに作ることより
バグが出た時に調べて直すことの方が大切です。

うまく動かない時間も
まったくの無駄という訳ではありません。

ゲームの仕組みを
より深く理解していく時間でもあります。

デバッグは面倒な作業に見えますが
ゲームを完成へ近づけるための
大切な制作の一部です。

「いつか、こんなゲームを作りたい」

広い世界を冒険するゲーム。
たくさんの人と遊べるゲーム。
物語やキャラクターが作り込まれたゲーム。

そんな大きな目標を持つことは
ゲーム作りを始める強いきっかけになります。

ただ
最初から夢のすべてを作ろうとすると
必要な作業の多さに圧倒されることがあります。

そんな時は
夢をあきらめるのではなく
小さな段階に分けてみましょう。

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

広い世界を作りたいなら
まずは一つの部屋を歩けるようにする。

たくさんの敵と戦いたいなら
まずは一種類の敵を作る。

長い物語を描きたいなら
まずは短い一場面をゲームにする。

小さく作ってみると

「何が必要なのか」
「どこが難しいのか」
「次に何を覚えればいいのか」

が見えやすくなります。

そして
一つ完成させるたびに
次の段階へ進むための力も増えていきます。

小さくすることは
夢を小さくすることではありません。

大きな夢に近づくために
今できる大きさまで切り分けることです。

遠くにある目標ほど
小さな完成を重ねながら近づいていけばいいと思います。

友達と一緒に遊べるゲームを作りたい。

とても楽しそうな目標ですが
一人用ゲームより難しくなることが多いです。

例えば
1台のパソコンで二人が遊ぶゲームでも

・同時に操作できるか
・キーの割り当ては分かりやすいか
・画面に全員の情報が収まるか
・片方だけが有利になっていないか

などを考える必要があります。

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

さらにオンラインで遊ぶゲームでは

・それぞれの画面で、キャラクターの位置や得点が同じ状態になるようにする
・通信環境の違いや遅れがあっても、大きなずれが起きないようにする
・途中で接続が切れた時の処理を作る
・二人が同じアイテムを同時に取ろうとした時、どちらが取ったことにするか決める

といった
一人用ゲームにはない仕組みも必要です。

そして難しいのは
作る時だけではありません。

一人用なら自分だけでも確認できますが
複数人用では実際に人を集めて

・二人でも四人でも正しく動くか
・同時に操作して問題が起きないか
・初めての人同士でも遊べるか

などを試す必要があります。

テストする人数や状況が増えるほど
確認することも増えていきます。

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

だから最初に作るなら

オンライン対戦を一台で遊ぶ二人用にする。
リアルタイム対戦を交互に操作する方式にする。（例：リバーシなど）
まず一人用として仕組みを完成させる。

というように
小さく始めるのもおすすめです。

「みんなで遊べる」は魅力的ですが
見た目以上に難しい目標です。

先に難しさを知っておけば
今の自分でも作れる形を考えやすくなると思います。

ゲームを作ろうと思った時

「こんなゲームを作りたい」

という目標があるのは
とても良いことです。

ただ
作りたいものによって
制作の難易度は大きく変わります。

例えば

・オンラインで対戦する
・広い3D世界を自由に歩く
・複雑な物理表現を使う
・たくさんの敵を賢く動かす
・データを保存して続きから遊べるようにする

こうした機能は
見た目以上に難しいことがあります。

また、シンプルに見えるパズルゲームでも
連鎖やクリア判定
絶対に解ける問題を作る仕組みなどが必要になると
難易度はかなり上がります。

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

だから
作り始める前に

「何が難しそうか」
「今の自分でも作れる部分はどこか」

を少し調べておくのがおすすめです。

難しいと分かったからといって
あきらめる必要はありません。

オンライン対戦を一人用にする。
広い世界を一画面にする。
複雑なルールを一つだけ試す。

このように
一番作りたい部分を残しながら
小さくすることもできます。

難易度を先に知るのは
夢を小さくするためではありません。

完成までの道を
見つけやすくするためだと思っています。

ゲーム制作と聞くと

「数学が得意じゃないと無理そう」

と思う人もいるかもしれません。

確かに
本格的な物理計算や3Dゲームを作るなら
数学の知識が必要になる場面はあります。

でも
最初から難しい数学が必要なわけではありません。

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

例えば

・キャラクターを動かす
・アイテムを取る
・敵に当たったらゲームオーバー
・スコアを増やす
・時間を数える

こういう小さなゲームなら
基本的な数字の扱いだけでも作れます。

むしろ最初は

「数字が増える」
「座標が少し変わる」
「条件を満たしたら処理する」

くらいの感覚で十分です。

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

作っているうちに

「もう少し自然に動かしたい」
「角度を使って飛ばしたい」
「ランダムに出したい」

という場面が出てきたら
その時に必要なことを少しずつ覚えれば大丈夫です。

数学が苦手だからといって
ゲーム作りをあきらめる必要はありません。

ゲーム制作は
数学を全部理解してから始めるものではなく、

作りながら
必要な分だけ覚えていくものでもあると思っています。

ゲームを遊んでいて

「自分ならこうするのに」
「ここ、もう少し変えたいな」
「このルールだったらもっと面白そう」

と思ったことはありませんか？

それは
ただの不満ではないかもしれません。

もしかすると
ゲームを作る側の視点が少し芽生えているのかもしれません。

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

例えば

・操作をもっと分かりやすくしたい
・難易度を少し変えたい
・別のルールを足してみたい
・見た目や演出を変えてみたい

そう考えることは
ゲーム作りの大事な入口になります。

最初から完全なアイデアを持っている必要はありません。

「ここを少し変えたらどうなるかな？」

という小さな気づきからでも
ゲーム作りは始められます。

遊んでいる時に感じた違和感や好みは
自分の作品を作る時のヒントになります。

「自分ならこうするのに」

その気持ちは
とても大切なものです。しっかりと育てていきましょう。

誰かと一緒にゲームを作るのは
とても楽しい経験になります。

でも
始める前に少しだけ決めておいた方がいいことがあります。

例えば

・どんなゲームを作るのか
・どこまで作ったら完成なのか
・誰が何を担当するのか
・作業できる時間はどれくらいか
・連絡や相談をどうするのか

このあたりです。

最初に何も決めずに始めると

「思っていたゲームと違う」
「どこまで作ればいいのか分からない」
「相手が何をしているのか分からない」

ということが起きやすくなります。

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

特に大事なのは
完成の形を小さく決めておくことです。

最初から大きなゲームを目指すと
途中で負担が大きくなりすぎることがあります。

また
作業量や使える時間は人によって違います。

だから

「無理なく続けられる形か」

を確認しておくことも大切です。

共同開発は
気合いだけで進めるより
先に少し話し合っておく方がうまくいきやすいです。

一緒に作る前に決めておくことは
相手を縛るためではありません。

最後まで楽しく作るための準備だと思っています。

ゲーム制作を調べていると

・Unity
・Godot

という名前をよく見かけます。

どちらも有名なゲームエンジンです。

でも初心者からすると

「難しそう」
「自分にはまだ早いかも」

と思うことがあるかもしれません。

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

実際、Unity や Godot は
Scratch や MakeCode Arcade と比べると
覚えることは多いです。

画面の見方
ファイルの管理
シーンの作り方
プログラムの書き方など
最初は戸惑う部分もあります。

でもそれは

「初心者には絶対無理」

という意味ではありません。

できることが多いぶん、最初に覚えることも多い
ということだと思います。

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

だから、いきなり大きなゲームを作ろうとすると
かなり大変です。

でも

・キャラクターを動かす
・ボタンを押したら反応させる
・簡単なミニゲームを作る

くらいなら
小さく学び始めることはできます。

大事なのは
最初から全部を理解しようとしないことです。

Unity や Godot は難しい部分もあります。

でも、小さく試せば
少しずつ慣れていける環境でもあります。

「難しいから無理」

ではなく

「できることが多いから、少しずつ覚える」

くらいに考えると
挑戦しやすくなると思います。

ゲームジャムには
制限時間があります。

48時間、3日、1週間など
決められた時間の中でゲームを作ります。

最初は

「時間が足りなそう」
「焦って作れなさそう」

と思うかもしれません。

でも
制限時間があるからこそ
決断が速くなることもあります。

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

普段の制作だと

「この機能も入れたい」
「もっと見た目を良くしたい」
「あとで直そう」

と考えているうちに
なかなか完成しないことがあります。

でもゲームジャムでは
時間が限られています。

だから

・今回は何を作るのか
・何を入れないのか
・どこまでできたら完成にするのか

を早めに決める必要があります。

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

これは
ゲーム制作ではかなり大事な練習です。

全部を完璧に作るのではなく
今の時間で形にする。

やりたいことを全部入れるのではなく
一番大事な部分を残す。

そういう判断力が鍛えられます。

制限時間は
ただ苦しめるためのものではありません。

迷いすぎず
完成に向かうための助けになることもあります。

ゲームジャムでは
「決める力」も大きく育つと思っています。

ゲーム作りに興味はあるけど

「高いソフトが必要そう」
「いいパソコンがないと無理そう」
「お金がかかりそう」

と思っている人もいるかもしれません。

でも
最初の一歩なら
お金をかけなくても始められます。

例えば

Scratch や MakeCode Arcade のように
ブラウザで使える無料の環境があります。

インストールなしで始められるものもあり
チュートリアルを見ながら
すぐに小さなゲームを作ることもできます。

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

もちろん
本格的なゲームを作ろうとすれば
必要になるものが増えることはあります。

でも最初から
高い道具をそろえる必要はありません。

まずは

キャラクターを動かしてみる。
ボタンを押したら反応させてみる。
アイテムを取ったら点数を増やしてみる。

それだけでも
ゲーム作りの楽しさは体験できます。

大事なのは
お金をかけることより
小さく試してみること。

「自分にもできるかも」

と思えるきっかけは
無料の環境でも十分作れると思っています。

ゲーム作りに興味はあるけど

「自分には無理そう」
「プログラミングなんて分からない」
「難しそうで始められない」

と思う人は多いと思います。

その気持ちはよく分かります。

ゲーム作りは
外から見るとかなり難しそうに見えます。

でも実際には
最初から大きなゲームを作る必要はありません。

キャラクターを動かす。
ボタンを押したら音を鳴らす。
アイテムを取ったら点数が増える。

それだけでも
もう小さなゲーム作りの一部です。

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

やってみる前から

「自分には無理」

と決めてしまうのは
少しもったいないかもしれません。

もちろん
簡単なことばかりではありません。

分からないことも出てきますし
思った通りに動かないこともあります。

でも、今は Scratch や MakeCode Arcade のように
初心者でも始めやすい環境があります。

AI に質問することもできます。

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

だからまずは
小さく試してみる。

10分だけ触ってみる。
チュートリアルを1つやってみる。
キャラクターを動かしてみる。

それで

「思ったより楽しいかも」

と感じるかもしれません。

無理かどうかは
やってみないと分かりません。

そして、最初の一歩は
思っているより小さくて大丈夫です。

ゲーム作りと聞くと

「難しそう」
「プログラミングができないと無理そう」
「ちゃんと勉強しないと始められなさそう」

と思うかもしれません。

もちろん
本格的に作ろうとすると大変な部分もあります。

でも
小さなゲーム作りは
思っているより「遊び」に近いです。

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

例えば

キャラクターを少し速くしてみる。
敵の数を増やしてみる。
ジャンプの高さを変えてみる。
アイテムを置く場所を変えてみる。

それだけでも
ゲームの感じ方は大きく変わります。

「こうしたらどうなるかな？」

と試して

「お、ちょっと面白くなった」
「これは難しすぎるな」
「この動き、なんか気持ちいい」

と反応を見る。

この繰り返しは、
かなり遊びに近い感覚です。

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

ゲーム作りは
最初からすごい作品を作ることだけではありません。

小さく試して
変化を楽しむことも
立派なゲーム作りです。

遊ぶのが好きな人なら
作る側の楽しさも
きっと感じられると思います。

ゲームを遊ぶのは好きだけど
ゲーム作りにはあまり興味がない。

そんな人も多いと思います。

でも
ゲームの裏側を少し知るだけで
遊び方が少し変わることがあります。

例えば、

・なぜこの敵はこの位置にいるのか
・なぜここでアイテムが手に入るのか
・なぜこのステージは少し難しいのか
・なぜこの操作は気持ちよく感じるのか

そういう部分には
作り手の工夫が入っていることが多いです。

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

もちろん
何も考えずに遊ぶのも楽しいです。

でも
少しだけ裏側を想像してみると、

「ここ、よく考えられているな」
「この失敗のさせ方、うまいな」
「この演出、気持ちいい理由があるのかも」

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

すると、同じゲームでも
プレイヤーとしての楽しさに加えて

作り手の工夫を見つける楽しさ

も味わえるようになります。

ゲーム作りを知らなくても
ゲームは楽しめます。

でも、ゲームの裏側を少し知ると
いつものゲームがもう一度おいしくなるかもしれません。

ゲームを作っている本人は
そのゲームのことを全部知っています。

ルールも
操作方法も
何をすればいいかも
どこが危ないかも分かっています。

でも
初めて遊ぶ人は違います。

何も知らない状態で
画面を見て、操作して
ルールを理解しようとします。

だから制作者にとっては簡単でも
プレイヤーには難しいことがあります。

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

例えば、

・どのボタンを押せばいいか分からない
・何を集めればいいか分からない
・敵と背景の区別がつきにくい
・失敗した理由が分からない
・次に何をすればいいか迷う

こういうことは
初めて遊ぶ人にはかなり大きな壁になります。

ゲームの難しさは
敵の強さやステージの難易度だけではありません。

「分かりにくさ」も
プレイヤーにとっては難しさになります。

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

だから
ゲームを作る時は時々

「初めて遊ぶ人には、これが伝わるかな？」

と考えてみるのがおすすめです。

自分では当たり前に見えているものほど
プレイヤーには見えていないことがあります。

プレイヤーの視点を想像するだけでも
ゲームはかなり遊びやすくなると思います。

ゲーム制作やプログラミングを学んでいると

「動かない」
「エラーが出る」
「思った通りにならない」

ということが何度もあります。

その時は
かなりつらいです。

でも実は
動かなかった経験こそ
一番の教材になることがあります。

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

教材どおりに作って動いた時は

「分かった気がする」

で終わってしまうことがあります。

でも
動かなかった時は違います。

「どこが違うんだろう」
「なぜこうなるんだろう」
「この命令は何をしているんだろう」

と考えることになります。

その過程で
ただ手順をなぞっていた時より
ずっと深く理解できることがあります。

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

もちろん
ずっと悩み続ける必要はありません。

AI にヒントをもらったり
コミュニティで相談したり
一度休憩したりしても大丈夫です。

大事なのは

「動かなかったからダメ」

と思わないことです。

動かなかったからこそ
気づけることがあります。

直せた時の経験は
次に同じような問題が起きた時
ちゃんと自分を助けてくれます。

動かなかった時間も
ゲーム制作の大切な学習時間なんです。

共同開発をしていると

「思ったより進んでいない」
「予定していた作業が終わっていない」

ということがあります。

そんな時
相手を責めたくなる気持ちが出ることもあるかもしれません。

でも
進捗を責めるだけでは、
あまり良い方向に進まないことが多いです。

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

相手にも

・作業が難しかった
・時間が取れなかった
・何をすればいいか迷っていた
・相談しにくくなっていた

など
いろいろな事情があるかもしれません。

もちろん
進捗確認は大事です。

でも大切なのは

「なんで進んでないの？」

と責めることではなく

「どこで止まっている？」
「何か手伝えることはある？」
「作業を小さく分けようか？」

と確認することだと思います。

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

共同開発では
相手を追い詰めるより
続けやすい状態を作る方が大事です。

責められると
報告や相談がしにくくなります。

逆に
相談しやすい雰囲気があると
問題が早く見つかりやすくなります。

進捗が遅れた時こそ
責めるより、状況を一緒に整理する。

それが
共同開発を成功させるために大切なことだと思います。

ゲームを完成させても

「公開するのは怖い」

と思うことがあります。

それは、
とても自然なことだと思います。

自分で作ったものを見せるのは
少し勇気がいります。

例えば、

・つまらないと言われたらどうしよう
・下手だと思われたらどうしよう
・バグが残っていたらどうしよう
・他の人の作品と比べられたらどうしよう

そんな不安が出てくることがあります。

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

特に初心者のうちは
作品を見せること自体がかなり大きな挑戦です。

でも
公開する作品が完璧である必要はありません。

小さな作品でも
少し不格好でも
完成させたことには価値があります。

そして公開すると
自分では気づけなかったことが見えることもあります。

操作が分かりにくい。
説明が足りない。
意外な部分を楽しんでもらえた。

そういう反応は
次の作品を作る時のヒントになります。

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

もちろん
無理に公開する必要はありません。

まずは友達に見せるだけでもいいし
小さなコミュニティに投稿するだけでもいいと思います。

大事なのは

「完璧になったら公開する」

ではなく

「今の自分が作ったものを、一度外に出してみる」

という経験です。

作品を公開するのが怖いのは
それだけちゃんと作ったからかもしれません。

怖さがあるのは
悪いことではないと思います。

「ゲームを作ってみたいな」
「ゲームの仕組みってどうなってるの」
と思う人は、一度やってみるといいですよ

ブラウザで作れる環境なら未経験でも大丈夫だと思います
よく分からない時は、ここで質問してください

とりあえず、1日30分を数日行えば、ゲーム作りの解像度がグッと上がります
ここがオススメです

迷走快走ゲームプログラミング入門

それから、何かを始めたいと思っても、なかなか始められないなぁと思っているなら「10日チャレンジ」というのをやってみてはどうでしょうか

『 なんか何もない日々を変える10日チャレンジ 』