とむ＠シマエナガゲームエンジニア

【クローズドβ テスター募集|25名】 個人開発のアプリ・ゲームを「お互いにテストし合う」場所を作りました！ ・作品の進捗を発信できる(devlog)
・観点を選んでテスト・感想を依頼できる
・バグ報告はテンプレで書きやすく
・辛口歓迎〜やさしめ、率直さの温度も選べる このポストに「参加希望」とリプをいただければ、招待コードをDMでお送りします。 
詳しく書きたい方はフォームからでも → docs.google.com/forms/d/e/1F… #Tokusa #個人開発 #ゲーム制作

「全部作り終えてからリリース」を目指していると 一生リリースできない。 MVG（Minimum Viable Game）という考え方がある。 【MVGとは】 ・市場に出せる最小限のゲーム ・「すべての機能」ではなく「コアループだけ」を持つ状態 ・プレイヤーのフィードバックを得るための最速の手段 【コアループを決める問い】 ・このゲームで一番楽しい瞬間はどこか？ ・その楽しさを体験するために最低限何が必要か？ ・それ以外は「あとで追加できる」か？ 【MVGを決める基準】 ✓ コアとなるゲームプレイが1サイクル体験できる ✓ 明確な開始・終了がある ✓ 遊んで「もう1回」か「ここを直してほしい」が言えるレベル 【実例：個人開発での判断基準】 ・ステージは3つあれば出せる（10個になるまで待たない） ・BGMが1曲あれば出せる（全ステージ分揃うまで待たない） ・アイテムが5個あれば出せる（20個揃うまで待たない） 「完璧なゲームを一人で作る」は幻想。 「小さく出して大きく育てる」が現実的な戦略。 #個人開発 #ゲーム制作

10月31日。 今年こそ「ハロウィンアップデート」を リリースするつもりだった。 ゲームはまだ開発中だった。 #個人開発 #ゲーム制作

#ゲーム制作 #ゲーム開発者と繋がりたい #個人開発者と繋がりたい 個人開発者に届けたい！📣 自分のゲームやアプリ、誰かに遊んでもらって感想がほしくありませんか？ 🐛 バグ報告 💬 初見の感想 🎨 UI/UXの改善提案 🔥 辛口フィードバックも歓迎！ 開発者同士で作品を磨き合える場所です🌱 tokusa.app/

個人開発者のみなさん、こんな経験ありませんか？👀 ・ゲームやアプリを作ったけど、遊んだ人の感想がほしい ・自分では気づけないバグを見つけたい ・率直な意見がほしいけど、知人には頼みにくい… そんな悩みを解決するサービス 「Tokusa（トクサ）」 🌱 🎮 作品を登録してテスターを募集 🐛 バグ報告やUI/UXのフィードバック 💬 初見の感想も受け取れる ✨ 辛口歓迎〜やさしめまで指定可能！ 開発者同士で作品をテストし合い、みんなで作品を磨いていきましょう！ 個人開発をもっと楽しく、もっと良く。 👇ぜひチェックしてみてください！ tokusa.app/ #個人開発者と繋がりたい #ゲーム開発者と繋がりたい

「英語対応したい」と開発後半で気づいたとき、 コード全体のテキストをハードコードしていた話。 ローカライズは後から入れるより最初から設計する方が楽。 【ローカライズを後回しにしたときの代償】 ・コード中のハードコードされた文字列を全て洗い出す作業 ・UIのレイアウトが英語の文字長に対応していない ・フォント問題（日本語フォントに英字が混在） 【最初から設計するための最小限のルール】 1. テキストはコード中に直接書かない（必ずKeyで管理） 2. テキストデータはScriptableObject or CSVで一元管理 3. UIはレイアウトが伸縮できる設計にしておく 【Unityの公式ローカライズパッケージ】 ・Localization Package（Package Manager > Unity Registry） ・StringTable / AssetTable でテキスト・画像を言語別管理 ・エディタ上でCSVをインポート/エクスポートできる 【最低限対応すべき言語（Steam向け）】 ・日本語（国内市場） ・英語（グローバル必須） ・中国語（簡体字：最大市場のひとつ） 英語対応するだけで潜在的な市場が5〜10倍になる。 「後でやればいい」が最も損をする選択。 #個人開発 #ゲーム制作

ゲームジャムを「ゲームを作るイベント」としてだけ使うのは もったいない。 戦略的に参加すると、フォロワー・フィードバック・実績を 同時に得られる。 【ゲームジャムの選び方】 ・itch.ioのjam一覧で参加者数・評価者数を確認 ・Ludum Dare / GMTK Game Jam / Global Game Jamが大規模 ・小規模ジャムはフィードバックの質が高いことが多い 【フォロワーを増やすための活用】 1. 制作過程をツイートで実況する（#ゲームジャム） 2. 完成品を投稿したらSNS・itch.ioのリンクを貼る 3. 他参加者のゲームをプレイしてコメントする（相互評価が生まれる） 【ゲームジャムで得られるもの】 ・短期間でのゲーム完成体験（スコープ管理の練習） ・プレイヤーからのフィードバック（評価コメント） ・コミュニティへの入り口（他の開発者との繋がり） ・ポートフォリオのための成果物 【注意点】 ・商用ゲームの試作として使う場合はライセンス規約を確認 ・48時間版を後からSteamに出す人も多い（Celeste等の実例あり） ゲームジャムの「完成させる経験」は 長期開発の挫折を減らすトレーニングにもなる。 #個人開発 #ゲーム制作

Steam年末セールまであと2ヶ月。 「セールに間に合わせてリリースしよう」と 毎年11月に思う。 毎年間に合わない。 #個人開発 #ゲーム制作

「作り終えてからSteamで調べたら 似たゲームが100本あった」 これは個人開発あるある。 マーケットリサーチは開発「後」ではなく「前」にやる。 【調べるべきこと（開発前）】 1. 同ジャンルの売れているゲーム（Steam上位） 2. そのゲームのレビュー内容（何が評価/批判されているか） 3. 価格帯（同ジャンルの相場） 4. ウィッシュリスト数・フォロワー数の目安 【SteamSpy / Gamalyticsで調べる】 ・SteamSpy：売上推定・プレイ時間・ジャンル傾向 ・Gamalytics：類似タイトルのトレンド・評価推移 ・Steam自体の「類似ゲーム」セクションも参考になる 【レビューから学ぶ】 ・低評価レビューは「避けるべき地雷」を教えてくれる ・高評価レビューは「なぜ売れているか」のヒントになる ・特定の機能への言及が多ければ差別化ポイントになる 【チェックリスト】 - [ ] 同ジャンル上位10タイトルのレビューを読んだか - [ ] 価格帯の相場を把握しているか - [ ] 自分のゲームの差別化ポイントを言語化できるか 「作れるか」と「売れるか」は別の問い。 売れるかを先に調べると、作るものが変わる。 #個人開発 #ゲーム制作

Unityのオーディオ、BGMと効果音の音量を スクリプトから変えるだけになっていないだろうか。 Audio MixerのSnapshotを使えば シーンの雰囲気に合わせた音の切り替えができる。 【Audio Snapshotとは】 ・Audio Mixerの全パラメータを保存した「状態」 ・TransitionToSnapshots()で状態間をスムーズに遷移できる ・ゲームプレイ・メニュー・水中・ポーズで音を切り替えるのに使う 【作り方】 1. Audio Mixerを開く 2. Snapshotsパネルで新しいスナップショットを追加 3. 各スナップショットでパラメータを調整して保存 【スクリプトからの切り替え】 // 水中演出でBGMをローパスフィルターで篭らせる AudioMixerSnapshot[] snapshots = { underwater, normal }; float[] weights = { 1.0f, 0.0f }; mixer.TransitionToSnapshots(snapshots, weights, 1.5f); // 1.5秒でクロスフェード 【活用例】 ・ポーズ中：BGMをローパスでぼかす ・ボス戦：リバーブを強くして緊張感を出す ・水中：全体をローパスフィルター ・メニュー：環境音のみ再生 「音でゲームの世界観が変わる」体験を スナップショット1つで作れる。 #個人開発 #ゲーム制作

個人開発でコードレビューがないこと、 最初は「自由だ」と思っていた。 半年後に自分のコードをレビューして 「誰だこれを書いたのは」となった。 自分だった。 #個人開発 #ゲーム制作

50人で起きたこと 登録者50人を超えたTokusaで、これまでに起きたこと: ・届いたレポートで、ゲームのアップデートが配信された
・有料素材をテストしたい声から「申請制」が生まれた
・テスターに称号ができ、実績のある人に依頼できるようになった 全部、使ってくれた人の声から生まれました。
 tokusa.app 
#個人開発 #ゲーム制作

スコアアタック系のゲームでは リーダーボードがあるかどうかで リピート率が全然違う。 SteamworksのリーダーボードをUnityから使う方法。 【Steamworksのリーダーボード種類】 ・Ascending（昇順）：タイムアタック系（低い方が良い） ・Descending（降順）：スコア系（高い方が良い） ・KeepBest / ForceUpdate：スコアの上書き方法 【基本的な実装（Steamworks.NET）】 // リーダーボードを検索/作成 SteamAPICall_t handle = SteamUserStats.FindOrCreateLeaderboard( "HighScore", ELeaderboardSortMethod.k_ELeaderboardSortMethodDescending, ELeaderboardDisplayType.k_ELeaderboardDisplayTypeNumeric ); // スコアをアップロード SteamUserStats.UploadLeaderboardScore( leaderboard, ELeaderboardUploadScoreMethod.k_ELeaderboardUploadScoreMethodKeepBest, score, null, 0 ); 【注意点】 ・リーダーボード名は後から変更できない ・Steamworks.NETかSteamworks SDKが必要 ・ローカルテスト時はSteamが起動している必要がある 【リーダーボード画面の設計】 ・世界ランク + 自分の周辺ランクを表示するのが定番 ・フレンドフィルターがあると遊び方が変わる スコアが可視化されるだけで 「もう1回やろう」が増える。 #個人開発 #ゲーム制作

Unityでプレイヤーキャラクターを動かすとき、 CharacterControllerとRigidbodyのどちらを使うか 最初に迷う人が多い。 【CharacterController】 ・物理演算を使わず移動を制御する ・Move() メソッドで直接移動量を指定 ・衝突判定は自動でやってくれる 向いている場面： ・アクションゲーム（精密な操作感が必要） ・プラットフォーマー（ジャンプのキレが重要） ・一人称視点シューター（FPS） 【Rigidbody】 ・物理演算によって動く ・AddForce や velocity で間接的に制御 ・摩擦・反発・重力の恩恵を受ける 向いている場面： ・物理ベースの挙動が必要なゲーム ・ラグドール・ロープ・車など ・投射物・障害物の動きが重要な場合 【よくある問題】 ・Rigidbodyでジャンプがふわっとしすぎる → CharacterControllerへ移行 ・CharacterControllerで物理的な押し合いが必要 → Rigidbodyが必要 【個人的な経験則】 ・アクション系 → CharacterControllerから始める ・物理挙動重要なもの → Rigidbody ・後から変えるのはコストが高いので最初に決める 「キャラクターの動き」はゲームフィールの核心。 ここだけは早めに決断を。 #個人開発 #ゲーム制作

「このステージ、チュートリアルが丁寧すぎるかも」 と思いながらテストプレイヤーを見ていたら 全員同じ場所で詰まった。 チュートリアルは丁寧にしすぎることはない。 #個人開発 #ゲーム制作

Tokusaの登録者が50人を超えました！！ 最初の1週間は4人でした。 一人ずつ声をかけて、作品を触って、感想を送って。 そこから少しずつ広がって、ここまで来ました。 登録してくれた皆さん、レポートを書いてくれた皆さん、本当にありがとうございます🙇 tokusa.app 
#個人開発 #Tokusa #ゲーム制作

アクセシビリティ設定のあるゲームは 「プレイヤーへの配慮」として好意的に受け取られる。 インディーゲームでも実装できる アクセシビリティ機能のリスト。 【視覚系】 ・テキストサイズ変更 ・カラーブラインドモード（赤緑色盲・全色盲） ・字幕・テキスト表示速度の調整 ・フラッシュ・点滅エフェクトのオフ 【操作系】 ・ボタンリマップ（キーコンフィグ） ・ホールド操作をトグルに変更 ・難易度設定の細分化（スピード・ダメージ倍率） 【音声系】 ・BGM / SE / ボイスの独立音量設定 ・モノラル音声オプション ・サウンドビジュアライザー（難聴対応） 【Unityでの実装例（カラーブラインド）】 // ポストプロセスのColorAdjustmentsで色調整 // または専用のシェーダーフィルターを適用 【参考資料】 ・Game Accessibility Guidelines （gameaccessibilityguidelines.…） ・Microsoft Inclusive Design 「配慮されている」という体験は レビューにポジティブな形で反映されることが多い。 #個人開発 #ゲーム制作

Unityでシーンが1つだけになっていないだろうか。 マルチシーン構成にすると 大きなゲームでも管理しやすくなる。 【マルチシーン構成とは】 ・複数のSceneを同時に開いて組み合わせる手法 ・シーンを機能別に分割することで並行作業がしやすい 【よくある分割パターン】 ・Persistent（常駐）シーン：GameManager・AudioManager ・UIシーン：HUD・メニュー ・Gameplayシーン：ステージ1, ステージ2 ・Debugシーン：開発中のみ読み込む 【実装方法】 // スクリプトから追加読み込み SceneManager.LoadScene("UI", LoadSceneMode.Additive); // アンロード SceneManager.UnloadSceneAsync("OldStage"); // シーン間でのGameObject移動 SceneManager.MoveGameObjectToScene(go, targetScene); 【メリット】 ・複数人が同じシーンを編集するコンフリクトが減る ・部分的にシーンを差し替えられる（デモ版の作成に便利） ・シーン単位でのテストがしやすくなる 【注意点】 ・DontDestroyOnLoadとの役割分担を明確にする ・Active Sceneの概念に注意（Instantiateの行き先） シーンが1つだと全員が同じファイルを触ることになる。 チームで作るなら早めに分割を検討する。 #個人開発 #ゲーム制作

「この前動いていたのに」 と言いながら git log を見ると 「fix: とりあえず」 「fix2」 「fix3（本物）」 というコミット履歴があった。 #個人開発 #ゲーム制作