「作りたいゲーム」と「売れるゲーム」を両立する方法

ゲーム開発においてしばしば語られるのが、「作りたいゲームを作るべきか」それとも「売れるゲームを作るべきか」という対立です。

automaton-media.com

しかし実際には、この二つは敵対するものではなく、異なる出発点をもつ創作の軸です。 それぞれの特徴を理解したうえで、「徹底模倣」と「基礎理解」という二つのアプローチを組み合わせることで、両立が可能する…というのがこの記事の趣旨となります。

1. 「作りたいゲーム」と「売れるゲーム」はなぜ対立するのか

■ 作りたいゲームを作る派

  • 強み: モチベーションが続く/独創性・熱量・個性を発揮できる
  • 背景: 自己表現・理想の実現・情熱が中心
  • 弱点: 市場とのズレが生じやすく、完成までに時間がかかるリスクがある

■ 売れるゲームを作る派

  • 強み: 現実的で継続可能/安定した収益・開発環境を得やすい
  • 背景: 市場理解・需要重視・現実主義
  • 弱点: 個性が失われやすく、作業的になってモチベーションを失う恐れがある

この二つの考え方は、一方が「内面の表現」、もう一方が「外界への適応」を重視していることで対立しているように見えます。 ですが、どちらも「良いゲームを作り続けたい」という目的自体は同じであるため、アプローチによっては両立することが可能です。

2. 両立の鍵:「徹底模倣」と「基礎理解」

「作りたいゲーム」と「売れるゲーム」をつなぐためには、"模倣を通して構造を掴み、理解を通して独自性を再構築する” ことが重要、と考えています。 ここで役立つのが「徹底模倣」と「基礎理解」という二つのアプローチです。

2-1. 「徹底模倣」:結果から本質に近づくアプローチ

「徹底模倣」とは、成功しているゲームを構造レベルで再現しながら本質を掴む方法です。 これは単なる「見た目」や「ジャンル」のコピーではなく、 “なぜその設計がプレイヤーを惹きつけるのか” を分析・再構築することです。

  • 目的: 成功事例の背後にある構造(ゲームループ・レベルや報酬の曲線)を理解する
  • 効果: “面白い / とっつきやすさ” の理由を実体験的に学べる
  • 「作りたいゲーム」では、参考タイトルの本質を損なわずに独自要素を加える
  • 「売れるゲーム」では、人気要素をコピーするのではなく「なぜそれが機能するか」を理解して再設計する

ここで挙げている模倣は「パクリ」「真似」ではなく「対象を観察することによる研究」を意味します。 成功した“ 結果” を通して、ゲームデザインの “因果” を掴む訓練を行います。

2-2. 「基礎理解」:原理から再構築するアプローチ

もう一つの方法である「基礎理解」とは、ゲームの面白さを原理・心理・構造から捉えるアプローチです。 つまり「なぜそれが面白いのか」の原理・原則を理論として説明できるようになることです。

  • 目的: ユーザー体験 (楽しい) の設計・プレイヤー心理・報酬を理論的に理解する
  • 効果: 「作りたい」感情を再現できる設計力を得る
  • 例えば、スイカゲームを参考にするなら、物理演算によるランダム性・リスクとカタルシスの関係を分析する
  • さらにそのジャンルの進化史を遡り、どんな取捨選択の上に現在の形があるのかを理解する

理解は「構造の抽象化」です。ゲームを構成する要素を徹底的に分解します。そしてその要素同士が別の要素とどのような関連性を持っているかを考えることです。 ゲームが持つ要素を足し算・引き算するだけではうまく行かないのは「要素同士」が持つ関連性を無視して、気に入らないというだけで要素を引き算してそのゲームの本質となる面白さが失われたり、なんとなく面白いと思った要素を足し算して回りくどく冗長なゲームメカニクスにして台無しにしてしまうことです。

そういった間違いをしないためにも、基礎要素の機能を理解して、感情的な “面白さ” を “再現可能な設計原理” へ変換できるようになるのが、ここで述べている「基礎理解」です。

3. 「徹底模倣」と「基礎理解」の関係

両者は真逆のようでいて、学びの入口と出口の関係にあります。

観点 徹底模倣 基礎理解
出発点 結果(成功例) 原理(なぜ面白いか)
学び方 体験・再現・分析 抽象化・理論化・再構築
得られる力 実感的な市場感覚 設計的な再現力・独自性
落とし穴 独創性を失う 理論偏重で面白さが薄れる

そのため、この2つの概念の理想的な関係は、“徹底模倣”で素材を集め、“基礎理解”で自分の言葉に翻訳することです。 模倣は「売れる構造」を学び、理解は「作りたい感情」を理屈で支える。 2つを往復することで、“自分が作りたいものを、売れる形で表現できるようになる…というのがベストな運用です。

4. 実践モデル:「模倣 → 理解 → 再構築」

結局ここまでの話は、単なる論理に過ぎません。 ではこの方法を実際に運用するためにはどうするのか。個人的には以下の手順で実践していくことをおすすめします。

  1. 模倣段階: 成功ゲームを分解・再現して“売れる構造”を掴む
  2. 理解段階: その構造の原理(面白さ・快感のメカニズム)を理論化
  3. 再構築段階: 理解した原理を自分の「作りたい」テーマに落とし込む
  4. 検証段階: 市場・ユーザーの視点から調整して磨く

まずは「模倣」によって、「作りたいゲーム」「売れているゲーム」を再現性のある形に落とし込みます。実際にゲームを再現する段階で得られた「面白さの要素」「原理原則」をできるだけ自分の言葉で説明できるようにします。 次に得られた理論をもとに既存のゲームの面白さの要素を複数組み合わせる、またはインスピレーションで得られたアイデアを少しずつ試していきます。これは何年もかけて開発を行うよりも数週間から数ヶ月といった短い期間のサイクルでリリースして、その反応を見ながら得られた結果が正しいかどうか検証すると良いです。

この循環によって、「作りたい」情熱を市場で伝わる形へ翻訳できるようになります。

5. まとめ:「模倣で学び、理解で超える」

以上、「作りたいゲーム」と「売れるゲーム」は、“模倣による実践”と“理解による理論”の往復で両立できるということでした。

  • 徹底模倣で「市場に伝わる文法」を学ぶ
  • 基礎理解で「自分の理想を設計する構造」を掴む
  • その往復を通して、“感情が伝わる設計”=作りたいし売れるゲームを実現できる

関連記事

短い期間でゲームを作ってリリースする方法として「Game A Week」(1週間でゲームを作る) という記事を書いているので参考になるかもしれません。

2dgames.jp

なぜ96%のインディーゲーム開発は失敗するのか

Why 96% of Indie Games Fail (なぜ96%のインディーゲーム開発は失敗するのか) という動画が面白かったので内容と個人的な感想をまとめておきます。 www.youtube.com

動画の内容

1. 情熱の置き所を間違えている

インディーゲーム開発者が、ゲームを作る動機の1つとして「脳内にある作りたいゲームのアイデアの実現」にあります。 ですが、これに情熱を注ぎすぎることで以下の問題が発生します。

  1. 技術不足:技術が足りないにも関わらずアイデア固執して開発が停滞する
  2. 表現力不足:アートや演出を表現する力がないこと気がつき萎えてしまう
  3. 結果が出ない:SNSで開発中の動画を出しても見向きもされない。体験版を作ってもプレイされない

こういった問題に直面することで「自分の能力・アイデアは大したことない」といった挫折を味わい、完成・販売までたどり着けない開発者が 75% (4分の3) いる、とのことです。

ただ、開発者は「アイデアへの情熱」ばかり見るのではなく、「開発のプロセス自体を楽しむ」ことにも注目すべきと主張しています。 例えば、John Romero(Doom開発者)は「アイデアではなく実行力が全て」と答えており、90作以上の経験を経て成功にたどり着いたという事例を紹介しています。

イデアを何も考えずゲームを作るわけではないですが、「能力不足」や「結果」といった目先の事象にとらわれずゲーム開発を楽しむのが大切、ということです。

2. プレイヤーの声を無視している

ゲームを作るモチベーションは「自分の好きなゲームを作る」です。このことは悪いことではなく、むしろ継続的なゲーム開発に大切なものです。 ここで問題となるのは、実際にゲームをリリースしたときに「市場が求めていないもの」だったときに話題にもならず売上にもつながらない可能性が高いということです。

そうならないようにするには、Fordの「馬の代わりに車を」的な話のように、プレイヤーの本質的ニーズを読み取ることが必要です。開発前にアイデアを持ってユーザーに聞きに行き、 フィードバックを得て検証することが重要です。

3. 市場調査をしていない

インディーゲームで成功するには「作りたいゲームが市場でどのように受け入れられるか」を考える必要があります。わかりやすいところでは「ジャンル」から目星をつけていきます。自分のゲームがどのジャンル/サブジャンルに属するのかを理解します。

サブジャンルというのも重要で、例えばパズルゲーム全体 と マッチ3パズル(Candy Crush系)では市場規模やユーザー層がまったく違います。これは経験や勘に頼らず "統計データ" から「誰がターゲットか」「市場の潜在規模はどれくらいか」「上位は大手が独占しているか」を調べることが重要です。具体的には Steamで配信するのであれば、Steamでそのジャンルを検索して、アイデアや価格、ボリュームを調査してみるのも1つの方法です。

例えば、マッチ3パズルは上位5社が市場の85%を占有し、平均的な作品は数千ドルしか稼げないという事実があります。そのため開発コスト次第で成功か失敗かが決まります。

4. マーケティング不足

多くのインディーゲーム開発者はマーケティングを軽視するか、間違った層にアピールしてしまっています。 単にPVやプレイ動画をSNSに投稿するだけでは売上につながりません。マーケティングは「価値の提供(教育・娯楽・感動)」であり、かつ 適切なオーディエンスに届けること が肝心です。

極端な例ですが、カジュアルなパーティゲームCounter-Strikeのファン層に宣伝しても効果が薄い、ということです。

まとめ:失敗を避けるための4つのステップ

  1. 情熱をアイデアではなく開発プロセスに向ける
  2. 開発前にユーザーの声を聞き、検証する
  3. 市場とジャンルを調査し、期待値を現実的に設定する
  4. 適切な層に価値あるマーケティングを行う

最後に動画は「失敗は視点次第。目標がリリースすることなら、それだけで成功」と締めくくっています。 つまり、アートとビジネスの両面を理解し、試行錯誤を続けることが成功への道だと強調しています。

改善のアイデア

以下は個人的に考える成功のためのインディーゲーム開発の改善案です。

1. 「小さく作って完成させる」習慣を持つ

作りたいゲームにもよりますが、1つの大きな夢のゲームを追い続けるのではなく、小規模なプロジェクトを何度も完成させるというのも1つの方法です。 例えばゲームジャム参加や「1週間で完成」を目標します。完成させることで「実行力」への自信がつき、挫折感を減らすことができます。 "Game A Week" に挑戦するのも良いかもしれません。 2dgames.jp もちろん有料で販売するには、クオリティを上げるための作り込みが必要です。ただ「面白くなるかどうかわからない」といった不安を抱えながら作るよりは、Game A Weekによってある程度面白さを確定してから、作り込みを行うほうが安定した開発を行いやすいと思います。

2. 「開発の習慣化」=楽しむためのルーチンを作る

ゲーム開発は短くても数ヶ月、長い場合は数年に及ぶことがあります。そういった継続的な開発を行うには、毎日15分でも「コードを書く・アートを描く・テストをする」という習慣を身につけることです。

2dgames.jp

さらに進捗を「今日はここまで進んだ!」と可視化することで、アイデアの結果に依存せず、プロセス自体の達成感を得られる。 100ノートやスマホのメモ帳にメモ書きをして残しても良いですし、TrelloやRedmineで小タスクを切って、チェックするのも効果的だと思います。

2dgames.jp

3. 「学び」と「創作」を一体化する

イデアが思うように実現できないときの「技術不足」や「表現力不足」を「学習チャンス」と捉えことです。 例えば「この演出を作れない」という問題に直面したときに挫折を感じるのではなく「ゲームエンジンやプログラムの機能を調べて動いた!」という流れを「小さな成功体験」にします。

これについて、開発ログや学習ログを残す(ブログやSNSで発信)と、自分の成長を客観的に感じやすくて良いと思います。

4. 「結果指標」を変える

ゲームを配信したときの指標を「ゲームの売上」や「SNSのいいね数」といった他人の反応を成功指標にすると挫折しやすいです。

そこで他人の評価ではなく「自分が何をできたのか?」を指標とします。例えば以下のものが考えられます。

  • 完成本数(例: 今年はゲームを3本完成させました、など)
  • 新しいスキル習得(例: 「シェーダーを1つ書けた」「敵のAIをうまく作れた」など)
  • 外部フィードバック回数(例: 「月1回はテストプレイヤーに触ってもらう」など)

といった「結果」ではなく「プロセス(過程)」中心の評価に切り替えます。

5. 「仲間」や「外部の目」を取り入れる

ゲーム開発は自分一人だと「技術不足 → 自分のせい」となりがちです。 そこで、Discordコミュニティや小規模チームで進めると、他人の進捗を見るだけで刺激になります。

「誰かが見ている・待っている」環境はモチベを支えます。

まとめ

まとめとしては以下のとおりです。

  1. 小さく完成させる習慣
  2. 開発そのものを楽しむ仕組み化
  3. 結果ではなく学びを成果として数える
  4. 仲間や外部の視点で孤立を防ぐ

すべてを取り入れるのは難しいかもしれませんが、部分的にでも取り入れることで、「アイデア固執して燃え尽きる」ループを避け「 ゲーム開発を実行する力」を身に着けやすくなると思います。

ChatGPTでメッシュデータを作る方法

今回はChatGPTでメッシュデータを作る方法について紹介します。

ChatGPTでメッシュデータを作る方法

ChatGPTのそのものにメッシュデータを作る機能はないのですが、以下のようなプロンプトを投げるとメッシュデータが作れます。

XXX のメッシュ (obj) を pythonで生成してください

例えば以下のような短剣画像を元にメッシュデータを作ってみます。

方法としては、画像データをChatGPTに添付して「この短剣画像のメッシュ (obj) を pythonで生成してください」といったプロンプトを実行します。

すると obj と mtl を生成してくれます。

作成したデータを添付しておきます。

内部的には Python コードを実行しているようなので「Pythonコードを教えて」と伝えると、Pythonコードが得られます。

細かく調整したい場合は、ChatGPTの対話で進めるよりも、このPythonコードを直接修正する方が早い場合があります。

なお生成される obj / mtl ですが、さすがに画像通りにはならず、スケールも極端に小さかったりするので、Blenderなどで調整する必要があります。

画像どおりのデータが欲しい場合は、Blenderなどで作り込む必要がありますが、ちょっとしたテストデータが欲しいだけであればこれで十分な気がします。

もしくはHunyuan3D-2などの Image to Meshライブラリで環境を構築します。検証はしていないですが、以下のページで構築方法を紹介されていますね。

qiita.com

ただ環境を作るのも簡単ではないので、お手軽に作りたい場合は今回の方法がおすすめです。

2DSTGを作るときに使えそうなボスの死亡パターンまとめ

アクションやSTGで使えるボスの死亡(爆発)パターンをまとめてみました。 だいぶ前に X (Twitter)にポストしていたのですが、文章化していなかったので改めてまとめておきます。

ボスの死亡パターンまとめ

HTML5のサンプル

HTML5で確認できるようにしておきました。

説明・操作方法

シンプルな死亡パターン

これは汎用的に使えるパターンかなと思います。

  1. 小さな爆発エフェクトを一定時間表示 (収束・溜め)
  2. その後、大きな爆発エフェクトを表示する (発散)

すぐに爆発せずに、溜めの時間を作ることで開放感を演出できます。

スロー再生

これは大爆発のタイミングをスロー再生にしたものです。 もう少しスローを遅くしても良さそう。

有名なところでは、斑鳩がこのパターンですね。

溜め演出に動きをつける

先に紹介した2つでも少しずつ落下する動きをつけていますが、これは画面内を飛び回るという派手な動きをつけたもので、ガンスターヒーローズなどで見られます。

横スクロールSTGでは重力で落下したり、縦スクロールSTGでは画面奥に落下する、といったバリエーションも考えられます。

部位破壊による爆風の反動

溜め演出として、ボスが持っている部位(武器、ファンネル、手、足など)少しずつ破壊していくパターンです。 爆風の反動でボスの本体が少しだけ動くとよりリアリティがあって良いと思います。

円の爆発+円の変形

爆発はテクスチャパターン以外にも図形描画する方法もあります。 これは円を徐々に広げて、縦方向に押しつぶすパターンです。 幾何学図形を使った演出はレイフォースがとても参考になります。

矩形を横方向につぶす

シンプルにかっこい演出を作る場合、矩形を横方向につぶすのがおすすめですね。 横STGよりも縦STGで使いたい演出です。

中心から光線を出現させる

内部から光エネルギーを放出した後に爆発するパターンです。 光線はTriangleポリゴンで描画します。 光線が横に伸びるとかっこいいので、横スクロールSTGで使いたいところ。

参考資料はダライアス外伝です。

中心から白い矩形が広がる

画面全体に白い板を重ねるだけのシンプルな演出で、実装コストも低く、使いやすい演出です。

白背景+暗転

背景を白飛びなどで明るくし、頂点カラーなどでボス本体を黒くします。 だいぶ特殊な演出ですが、世界観にマッチするものであれば使っても良いかもしれません。

特殊

2値化やラスタースクロールなど特殊な効果による爆発パターン。 ここまでになるとセンス次第というところで、作り込みに時間が結構かかります。 今回紹介した爆発パターンでは一番時間をかけてつくりました。 参考資料はメタルブラックです。

ソースコード

Godotで作成したものですが、ソースコードGithubにアップロードしています。

HTML5出力したゲームを itch.io へアップロードする方法

今回は itch.io へのゲームのアップロード方法について説明します。

なお、アカウントは作成済みとして説明をしていきます。

itch.io へのゲームアップロード方法

itch.io とは

itch.io とはインディーゲームを購入して遊んだり販売したりできるサイトで、主に個人開発者が海外向けにゲームを販売する場合によく使われます。Steamよりはお手軽にアップロードできるので、ちょっとしたゲームを公開するのに向いていると思います。

言語設定

もし言語を日本語にしていない場合は、以下の手順で日本語に設定できます。

左上のアカウント設定から「Settings」を選びます。

そしてプロフィールページから、言語らしきところのドロップダウンを「Japanese」にして「Save」で保存するとインターフェースが日本語になります。

プロジェクトの作成

日本語化されると、メニューに「ダッシュボード」と表示されるのでそれをクリックし、「新しいプロジェクトを作成」を選びます。

作成画面が表示されるので、各項目を入力してきます。

  • タイトル:ゲームタイトル(できれば英語で)
  • プロジェクトURL:特にこだわりがなければ、タイトルから自動入力されるものを使用する
  • 短い説明またはキャッチコピー:任意で入力します
  • 種類:ゲーム
  • プロジェクトの種類:今回はHTML5で出力したものをアップロードするので「HTML」とします
  • リリース状況:公開済み(完成している場合)
  • 価格設定:無料の場合は「$0か寄付」。そうでなければ「有料」
  • ファイル一覧:アップロードするファイルをZIPにしたものをここからアップロードします
  • ViewportのディメンションHTML5の場合はここに解像度を設定する
  • 公開範囲とアクセス:最初は「非公開」「限定公開」しか選べないようで、動作を確認したら公開ステータスにします

ファイルのアップロード

アップロードするファイルは ZIP に固めておきます。Godot で HTML5出力したものをそのまま ZIPファイルにしました。(Godot で出力されたものはそのままZIPにして問題なさそうです)

実行ファイルの場合は「Executable」を選び対応プラットフォームを選択します。今回はHTML5なので、「このファイルはブラウザでプレイされます」を選びました。

カバー画像

カバー画像は必須なので、作成して登録しておきます。(630 x 500 が推奨のようです)

投稿のプレビュー

保存すると以下の画面が表示され、「Edit theme」からプロジェクトの情報を編集できる旨のメッセージが表示されます。「Got it」をクリックします。

すると画面の中央に「Run game」ボタンが表示されるので、これをクリックしてゲームの起動を確認します。

公開ページの調整を行う

まだステータスは「DRAFT」となっているのでこれをクリックして情報を編集します。

調整が必要であれば修正を行います。

公開する

問題がなければ「公開範囲とアクセス」から「公開」を選び「保存」ボタンをクリックすると公開されます。

参考

有料で販売したい場合には以下の記事が参考になりそうです。

私は PayPal アカウントを持っていたので、そのまま PayPal で設定しました。少し悩んだのがビジネスアカウントにするかどうかですが、特に個人アカウントでも問題ないようだったのでそのままとしておきました。

【Godot】Stomping Shooterで使った技術と得られた知見まとめ

Godot Engine Advent Celendar 2022 15日目

この記事はGodot Engine Advent Celendar 2022 15日目の記事となります。


Godot Engineでのゲームの試作として上に登るアクションゲームを作ったので、得られた知見と使った技術をまとめてみました。

ゲームの情報とプロジェクト

まずゲームの紹介です。ゲームは itch.io にアップロードしています。

ソースコードGitHubからダウンロードできます。


得られたもの

今回のゲームで使用したGodot の機能

一方通行コリジョン

一方通行床コリジョン」を使ってアクションゲームを作る…ということがこのゲームを作ったきっかけとなります。

ただ一方通行床コリジョンだけだと、横からの当たりが抜けてしまいます。

このコリジョン抜けがあると、理不尽な落下死が発生しやすくなってしまうので、コリジョンを2つ重ねて横からの衝突時には上にプレイヤーを押し上げるようにしました。

コリジョンは以下のようにStaticBody2D を外側に配置して、Area2Dを内側に入れています。できればArea2Dだけで判定したかったのですが、コリジョン抜けが発生したり接地判定がうまく取れなかったのでこのような実装となりました。

ホーミングレーザー

敵を攻撃するホーミングレーザーは以下の記事をもとに作りました。

バレットタイム(スロー再生)

青い玉を取得したときに、敵弾などがスロー再生されます。

これは _process() / _physics_process() の delta にバレットタイムの係数を掛けることで対処しました。

func _process(delta: float) -> void:
    # バレットタイムの係数を掛ける
    delta *= Common.get_bullet_time_rate()

    _velocity += _accel
    position += _velocity * delta;
    
    # 画像の回転.
    rotation = atan2(_velocity.y, _velocity.x)

スロー再生する他の方法として Engine.time_scale の値を変更することでスローにできますが、プレイヤーの速度はそのままとしたかったので、この方法は使用しませんでした。

 

ヒットストップの実装方法

敵に接触した際に発生するヒットストップは停止したいオブジェクトの set_process() / set_physics_process() を呼び出すことで実装しています。RigidBody2D 以外はこれですべて一時停止できます。

# 一時停止状態を切り替える
func _set_process_all_objects(b:bool) -> void:
    for obj in _main_layer.get_children():
        obj.set_process(b)
        obj.set_physics_process(b)
    for item in _item_layer.get_children():
        item.set_process(b)
        item.set_physics_process(b)
    for wall in _block_layer.get_children():
        wall.set_process(b)
        wall.set_physics_process(b)
    for bullet in _bullet_layer.get_children():
        bullet.set_process(b)
        bullet.set_physics_process(b)

 

 

リアルタイムのBGMの変化

BGMは新しい敵が出現したときにシームレスに切り替えています。曲のテンポは 148 BPM・4拍子・8小節で統一しているため、1小節単位で新しい曲に切り替えるようにしました。

    if _now_bgm != _next_bgm: # BGMのIDに変更があった
        var _can_change = true
        if _bgm.playing:
            var pos = _bgm.get_playback_position()
            var measure = 13.01 / 8 # 13.01秒 / 8小節.
            var d = fmod(pos, measure)
            if 0.1 < d and d < measure - 0.1:
                _can_change = false
        if _can_change:
            # BGM変更.
            _now_bgm = _next_bgm
            _bgm.stream = load("res://assets/sound/stage%d.mp3"%_now_bgm)
            _bgm.play()

またバレットタイムに入ったときに、"bitch_scale" を 0.75 に減らしてローパスフィルタを適用しています。

    if Common.is_slow_blocks(): # バレットタイム中.
        _bgm.pitch_scale = 0.75
        AudioServer.set_bus_effect_enabled(1, 0, true) # ローパスフィルタを有効にする.
    else:
        AudioServer.set_bus_effect_enabled(1, 0, false) # ローパスフィルタを無効にする.
        _bgm.pitch_scale = 1.0

ローパスフィルタとは「低音だけを通す(くぐもった音になる)」という効果を持つエフェクターで、活発でない印象を与えることができます。ゲームスピードが低下していることを感じさせるのに適していると思ってローパスフィルタを採用しました。

エフェクターの設定方法については以下の記事に書いています。

またBGMは「4小節がイントロ」+「4小節がループ区間」という作りになっていて、区間リピートの設定方法は以下の記事に書いています。

プログレスバー

画面の上部に表示されているプログレスバーは以下の記事を元に作りました。

BMPフォント

今回使用したフォントはBMPフォントを使っています。TTFだと固定幅でよい感じのものが見つけられなかったのでBMPフォントを使いました。

BMPフォントは ShoeBox を使用して作っています。

 

ただShoeBoxで固定幅の設定がうまく設定できず、以下の記事を見つけて対応しました。

  • Txt MonoSpace
    固定幅フォントにするかどうかの設定です。ヘルプにはそのようにできると解説がありますが、試してみた限り固定フォント書き出しにはなってくれませんでした。。File Format Loop設定のadvanceX設定を固定値にしてしまえば近い感じにではできます。
ShoeBox:ビットマップフォント書き出し設定の解説(#4詳細編)

ちなみにフォント画像は「おめが試作設計局」の「芝が生えるゲーム」からお借りしています。(他にも敵画像を「えぐぜりにゃ〜」からお借りしています)

その他・得られた知見

CanvasLayerにインスタンスをまとめておいて共通モジュールからアクセスできるようにする

アクションゲームを作る場合、特定のグループに所属するインスタンスを取得したり登録したりしたくなることが多いですが、共通モジュールに CanvasLayer をまとめて登録することで対応しました。

    # レイヤーテーブルを作っておく.
    var layers = {
        "wall": _block_layer,
        "item": _item_layer,
        "enemy": _enemy_layer,
        "shot": _shot_layer,
        "bullet": _bullet_layer,
        "effect": _effect_layer,
    }
    # 共通モジュールに登録する
    Common.setup(self, layers, _player, _camera)

Commonは常駐(自動読み込み)のスクリプトなので、これでどこからでも各オブジェクトにアクセスできるようになります。

        # _bullet_layerを取得.
        var bullets = Common.get_layer("bullet")

        # 爆発オブジェクトを生成.
        var blast = BlastObj.instance()
        blast.position = position

        # _bullet_layerに登録.
        bullets.add_child(blast)

AudioStreamPlayer は共通モジュールにまとめてプールしておくのが楽

AudioStreamPlayer は同時再生するSEの数だけ共通モジュールにまとめてプールしておくと、再生が簡単にできて使い勝手が良いです。

# サウンドデータのパステーブル.
var _snd_tbl = {
    "damage": "res://assets/sound/damage.wav",
    "explosion" : "res://assets/sound/explosion.wav",
    "coin": "res://assets/sound/coin.wav",
    "flash": "res://assets/sound/flash.wav",
}

func setup(root, layers, player:Player, camera:Camera2D) -> void:
    # ゲーム開始時に一度だけ呼び出される関数
    ...
    
    # MAX_SOUND の数だけ AudioStreamPlayer を作って登録しておく
    for i in range(MAX_SOUND):
        var snd = AudioStreamPlayer.new()
        snd.volume_db = -4
        root.add_child(snd)
        _snds.append(snd)

そして再生するときにあらかじめ確保していた AudioStreamPlayer を使います。

func play_se(name:String, id:int=0) -> void:
    if id < 0 or MAX_SOUND <= id:
        push_error("不正なサウンドID %d"%id)
        return
    
    if not name in _snd_tbl:
        push_error("存在しないサウンド %s"%name)
        return
    
    var snd = _snds[id] # idに対応する AudioStreamPlayerを取り出す
    snd.stream = load(_snd_tbl[name]) # SEをロードする
    snd.play() # 再生

カメラのスムージングとカメラ揺れの共存

カメラのスクロールは smoothing をオンにしておくと滑らかにスクロールしておすすめです。

問題点として、カメラを揺らすときにカメラの position の移動がゆっくりになって激しい揺れができなくなります。そこで、カメラを揺らす場合には smoothing_enabled無効にして揺らすようにしています。

## カメラ揺らしの開始.
func _start_camera_shake(type:int) -> void:
    # カメラ位置を保持.
    _camera_shake_type = type
    _camera_shake_position = _camera.position
    _camera_shake_timer = TIMER_SHAKE
        
    # スムージングを無効化.
    _camera.smoothing_enabled = false

RigidBody2D はアクションゲームに向いていないかもしれない

大根ミサイルは壁にぶつかると反射します。この挙動を楽に作りたかったので、最初は RigidBody2D を使って実装していました。

ただ今回のゲームでは、ヒットストップやスロー再生など特殊な挙動があったため RigidBody2D だと細かい制御ができず、結局は Area2D に置き換えました

func _process(delta: float) -> void:
    delta *= Common.get_bullet_time_rate()
    position += _velocity * delta
    
    # 横壁は固定なのでこれで反射が実装できる
    var left = Common.TILE_SIZE * 1.5
    var right = Common.SCREEN_W - Common.TILE_SIZE * 1.5
    if position.x < left:
        position.x = left
        _velocity.x *= -1
    if position.x > right:
        position.x = right
        _velocity.x *= -1
    
    _spr.rotation = atan2(_velocity.y, _velocity.x)

RigidBody2D は物理アクションなど、物理法則に準拠した挙動をするオブジェクト向きでアクションゲームにはあまり向いていないのかもしれません。

ゲームデザイン的な話

高さ・重力のあるプラットフォーマーでの弾避けは難しいので、そのあたりの落としどころを見つけるのに苦労しました。具体的には2体目の敵を作ったあたりで、弾幕シューティングとアクションの組み合わせをどのように広げていくかの方向性の考えがまとまらない状態となりました。

そこで、名作2Dアクションシューティングとして人気の高い ガンスターヒーローズ を少しだけ参考にしました。

セブンフォースのこの形態の攻撃方法(レティクルを移動させて攻撃する)は「使える!」と思って採用した次第です。

ということで以下が実装した攻撃方法です。

ガンスターヒーローズの場合はレティクルに向けて発射するだけですが、今回のゲームでは、この攻撃方法と別の攻撃やトゲ床が組み合わさることでアクションのバリエーションを感じさせるようなものとなりました。

やはり既存の似たジャンルのゲームを参考にするのは基本であり、得られるものが多い…ということを改めて理解した次第です。

また「最初のアイデア固執しない」ということも大切かなと思いました。1つのメカニクス固執して、それを複雑に拡張するのではなく、別の軸の新しいメカニクスを採用する(その敵固有の攻撃方法を追加する)のも時として良い効果を発揮することもある事例かな…と思いました。

それと敵弾を無効化するアイテムをいくつか用意して、「弾避け」よりもそれらのアイテムを使うタイミングを選ぶ自由度を組み込み、「足場に飛び移るタイミングを探るゲーム」という面白さも表現できたのでは…と思っています。

【2022年】ゲーム開発で使っている環境・ツールの紹介

2022.12.7現在、私が使っているゲーム開発環境を紹介します。

PC

PCは M1 Mac mini (2020)Macbook (2016) を使っています。ただ macOSは、ゲーム開発に関連するツールが「Windowsでしか使えない」「対応していない」「Windowsと比べて使い勝手が悪い」など Windows 環境に比べて不利な点が多いので、あまり人にはおすすめできない環境です。例えば Unity を使うにしても Visual Studio が使えないとか、UE のパフォーマンスも macOS版はあまり良くないとか…。GameMakerもmacOSでしか発生しない不具合もいくつかありました。

ということで、単に個人的なこだわりで使っています…。

ゲームエンジン

GameMaker

使用頻度:★★★★★

GameMaker は2Dゲームがとても作りやすいゲームエンジンです。(月額500円〜)

なんだかんだで 10年近く使っているゲームエンジンで、最近配信した「旧校舎に咲く花」もこのツールで作りました。

Unity や UE と比べるととてもシンプルな環境なので、ゲームを作ったことがなかったり Unity や UE に挫折した方は試してみても良いかな、と思っています。サブスクリプションですが、お金がかかるのは実行ファイルを作るタイミングなので、ゲームが完成するまでは実質無料です

特徴としては、ほぼ2Dゲーム専用なのですが、用意されているAPIがシンプルでやりたいことがすぐできる環境だと思っています。

ただ次回作からは、Godot Engine に移行する予定です。

 

Godot Engine

使用頻度:★★★★

Godot Engine は Unity に似たノードシステムを持つゲームエンジンです。(無料)

メリット・デメリットは以下の記事に書いています。

余分な機能はデフォルトで用意しない、という思想があるせいなのか動作が軽快で、かなり低スペックなノートPCでもサクサク動いてくれるのがありがたいです。

今後のゲーム開発の主力として使っていく予定のゲームエンジンです。

エディタ

Visual Studio Code

使用頻度:★★★

 

Visual Stuiod Code は無料で使えるコードエディタです。ソースコードを書くのに必要な機能が一通り揃っています。

私は主に Python や 自作アドベンチャースクリプトを書くために使用しています。Godot Engine の GDScript はこちらで書いたほうが効率が良いとのことです。

Scrivener

使用頻度:

Scrivener はシナリオを書くことに特化したワードプロセッサです。1万円近くするのであまりおすすめできませんが、シナリオの構成やキャラ設定をまとめるのに特化した便利ツールです。

最近配信した「旧校舎に咲く花」も、このツールでキャラの設定をまとめたり、各シーンの情報を整理したりしていました。

Mind Note

使用頻度:★★

Mind Noteマインドマップ作成ツールです。アイデアをひねり出したりアイデアを整理するのに使っています。

macOS版のみですが、デザインがとてもキレイで使っていて楽しいですね。有料版にすると iPad と連動できるみたいですが、iCloud同期で十分使えて、サブスクリプションで使うほど使用頻度も高くないので無料版を使っています。

アート

CLIP STUDIO PAINT

使用頻度:★★★★★

最近は脱出ゲームをメインに作っていて、必要な素材はほとんどこのツール (クリスタ) で作っています。イラストを書くのにとても向いているペイントツールですが、単に画像編集ツールとしても軽くて使い勝手が良いというメリットもあります。

そして個人的によく使っているのが CLIP STUDIO ASSETS という、Unityでのアセットストアみたいなものです。

CLIP STUDIO ASSETS はブラシやテクスチャだけではなく、クリスタで読み込める 3Dモデルなどもあり、背景素材はここで手に入る3Dモデルの背景を使用しています。

なお CLIP STUDIO PAINT は最近、月額のサブスクリプションに移行したことで批判があるようですが、月額にしておおよそ数百円 (年3000円程度) なので個人的には許容範囲なので良しとしています。それとサブスクリプション支払いにすると、月に公式素材が3つ無料で使えるというメリットも個人的には嬉しいです。

ただ最近のお絵かきツールは無料のツールでもクオリティが高くて、MediBang Paint. や Krita などは無料で使えるので、「サブスクはちょっと…」という方はこちらを使ってみても良いのかもしれません。

Adobe Photoshop

使用頻度:★★★

Photoshop は主にUI素材やサムネイルやバナー素材を作るのに使っています。

個人的に考える Photoshop を利用するメリットは以下のとおりです。

  • 画像の調整がすごく楽にできる:UI素材やバナー画像が作りやすく、レイヤー効果や位置の調整が楽にできる
  • Adobe Fonts が使える:フォントを探す時間を短縮できる
  • ニューラルフィルタでの色味の調整が楽にできる
  • 作りたい画像や効果の方法を検索するとすぐに情報が見つかる

月額・年額制のサブスクリプションを採用しているのが不評で、Photoshopをそのまま買うと年額3万近くかかってしまうのですが、「フォトプラン」を使用すれば年額 1万3000円 ほどになりますので「それくらいならいいかな…」と必要経費として支払っています。

Aseprite

使用頻度:★★

Asperity は 2Dドット絵の作成に向いたツールです。最近はドット絵を描くことが減ったので使用頻度はやや下がっています。

Spine

使用頻度:

Spine は2Dの画像にボーンやメッシュを入れてアニメーションさせるためのツールです。基本機能のみの「Essential版」とフル機能の「Professional版」がありますが、ボーンやメッシュ変形は Professional版になるので、実質こちら一択ですね。円安の影響もあって4万円超えの結構なお値段になってしまっていますが、イラストをベースとした2Dゲームのクオリティを上げたい場合はおすすめのツールです。

最近の使用頻度はほぼゼロに近いのですが、PVを作るときにキャラクターの髪や服を揺らしたりしてリッチに見せることができるので、そのあたりで使ってみたいな…などと考えています。

あと Godot も正式に対応したので、何かしら使う機会があるのかもしれません。

サウンド

FL Studio

使用頻度:★★

FL Studio ダンスミュージックの制作に特化した DAW (作曲ツール) です。おおよそお値段は 3〜4万円ほどですが「ライフタイムフリーアップグレード」という、一度買うと一生使える(バージョンアップ時の支払いもなし)とてもお得なライセンスとなっています。

ちょっとしたBGMが欲しいときに使っています。

ただ作曲もあまりしなくなったので、使用頻度は低めです。

Audacity

使用頻度:★★★

Audacity は無料で使えるサウンド編集ソフトです。主に効果音の編集ソフトとして使っていて、無音部分を削る、音量の調整などで大活躍しています。

GameSynth

使用頻度:★★

GameSynth は効果音を作成することに特化したツールです。お値段は 4万円近くとかなりお高いですが、年末あたり (11〜12月)に半額セールを行うことが多いようなので、それを狙うのが良いです。

なかなか手を出しづらいお値段ですが、豊富なプリセットがあって欲しい効果音を探す時間を短縮できるのでかなりおすすめのツールです。

ちなみに 2022.11.19現在、macOSで動作しないので、このツールだけ Windows で使用しています。

その他

CastleDB

使用頻度:★★★

CastleDB はゲーム用に特化した静的なデータベースです。個人的にとても扱いやすいのですが、なぜか使っている人がほとんど見つからないツールです。これが使われている最も有名なゲームは Dead Cells なのですがそれくらいですね。

おそらくマイナーすぎる環境(Haxe)用のツール で情報が少なすぎるので使い方がわからなかったり、エディタの更新が止まっていたりするのが問題なのかもしれません。

ただデータは普通の JSON 形式なので、JSONファイルが読み込めればどの環境でも使用可能で、私は GameMaker や Godot で CastleDB のデータを使えるようにしています。

GitHub Desktop

使用頻度:★★★★★

GitHub Desktopソースコードを管理する Git のリポジトリをまとめたサービスにアクセスするためのツールです。一般公開したくない場合はプライベートリポジトリも無料で作れるのが良くて使い続けています。

Redmine

Redmineはタスク管理ツールとして使っています。

タスクボードも併用しているのですが、複雑なプロジェクト管理としては個人的にこれが最適解ですね。

以下のページにも書いたのですが、Redmineはタスクをどこまでも階層化できるのがお気に入りで、仕事でもお世話になっています。

macOS標準アプリ

macOS標準アプリは使いやすいものが多くて、いくつか使っています。

  • Keynote: Windowsのパワーポイントのようなもの。画像素材や資料作りに役立っています
  • QuickTime Player: 画面をキャプチャして動画を作ったり簡単な編集ができます。ちゃんとした動画編集をする場合は「Final Cut Pro (有料)」を使っています

Dockerのインストール手順とNakama Serverのインストール方法

この記事では、Dockerをインストールして、オープンソースのゲームサーバー「Nakama Server」をインストールする方法について書いていきます。

環境

今回のインストールを試した環境とバージョンは以下のとおりです

  • Windows 10 64ビット Pro
  • Docker Desktop 4.11.1

Dockerのインストール手順

インストーラーを入手

インストーラーは以下のページから取得します。

「Docker Desktop for Windows」をクリックすると、ダウンロードが開始します

そしてダウンロードした「Docker Desktop Installer.exe」を実行します。

インストール

なお、システム要件としては、以下のとおりです

  • Windows 10 64ビット
  • 4GBのシステムメモリ
  • ハードウェア仮想化が BIOS設定で有効とされていること

最後の条件がよくわかりませんが、普通にWindowsが動いていれば大丈夫なのかなと…

まずは基本設定のようです。

WSL2は有効にした方が良さそうなので、そのままにしておきます。ショートカットも不要なら後で削除すればいいので、そのまま「OK」で良いのかなと…

するとインストールが始まるので、しばし待ちます…

インストールが完了すると「Close and restart」が表示されるので、これをクリックしてPCを再起動します

インストールが完了すると「Close and restart」が表示されるので、これをクリックしてPCを再起動します

そして再起動が完了するとDockerが立ち上がって、同意を求められるので「I accept the terms」にチェックを入れて、「Accept」をクリックします

しばらくすると「WSL 2 installation is incomplete.」と表示されることがあります。

WSL 2のインストール

「WSL 2 installation is incomplete.」と表示される場合は、WSLの更新プログラムが必要とのことなので、ダイアログのリンク「https://aka.ms/wsl2kernel」をクリックします

そしてリンク先の手順通り、WSLの更新プログラムのインストーラーをダウンロードして、インストールを行います。(wsl_update_x64.msiを実行する)

「Next」ボタンをクリックして Linuxカーネルをインストールします。

「Finish」ボタンを押してインストールを完了します

WSL 2の設定(※これは不要かもしれません)

先程のページ (https://aka.ms/wsl2kernel) の指示に従い、PowerShellを起動します

そして以下のコマンドを実行します

Power Shell
> wsl --set-default-version 2

実行すると、

WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください
この操作を正しく終了しました。

と表示されれば、WSL 2が有効になる…ようです

このウィンドウが残っていれば「Restart」でDockerを再起動します

残っていなければ、デスクトップのショートカットからDockerを起動すると…

このような画面が表示されれば、Dockerが動いていそうな感じです

Nakama Serverのインストール

オープンソースのゲーム用サーバー「Nakama Server」をインストールします

以下のページを参考にしました

インストール場所は、とりあえずデスクトップに作成するとします

デスクトップに「nakama」フォルダを作成し、「docker-compose.yml」を作成します

version: '3'
services:
  cockroachdb:
    image: cockroachdb/cockroach:latest-v20.2
    command: start-single-node --insecure --store=attrs=ssd,path=/var/lib/cockroach/
    restart: "no"
    volumes:
      - data:/var/lib/cockroach
    expose:
      - "8080"
      - "26257"
    ports:
      - "26257:26257"
      - "8080:8080"
  nakama:
    image: registry.heroiclabs.com/heroiclabs/nakama:3.12.0
    entrypoint:
      - "/bin/sh"
      - "-ecx"
      - >
        /nakama/nakama migrate up --database.address root@cockroachdb:26257 &&
        exec /nakama/nakama --name nakama1 --database.address root@cockroachdb:26257 --logger.level DEBUG --session.token_expiry_sec 7200 --metrics.prometheus_port 9100        
    restart: "no"
    links:
      - "cockroachdb:db"
    depends_on:
      - cockroachdb
      - prometheus
    volumes:
      - ./:/nakama/data
    expose:
      - "7349"
      - "7350"
      - "7351"
      - "9100"
    ports:
      - "7349:7349"
      - "7350:7350"
      - "7351:7351"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:7350/"]
      interval: 10s
      timeout: 5s
      retries: 5
  prometheus:
    image: prom/prometheus
    entrypoint: /bin/sh -c
    command: |
      'sh -s <<EOF
        cat > ./prometheus.yml <<EON
      global:
        scrape_interval:     15s
        evaluation_interval: 15s
      scrape_configs:
        - job_name: prometheus
          static_configs:
          - targets: ['localhost:9090']
        - job_name: nakama
          metrics_path: /
          static_configs:
          - targets: ['nakama:9100']
      EON
      prometheus --config.file=./prometheus.yml
      EOF'      
    ports:
      - '9090:9090'
volumes:
  data:

(※最新の設定ファイルは「https://heroiclabs.com/docs/nakama/getting-started/install/docker/」から確認するようお願いします)

そうしたら、docker-compose.yml を作成したフォルダに移動してコマンドプロンプトを開き、

コマンドプロンプト
> docker compose up

を実行すると、Nakama Server のインストールが開始します。

また、インストール中にアクセス許可を求められる場合は「アクセス許可」をクリックします。

Dockerに「nakama」が表示されて「Running」となっていればインストール完了です。

実際に動いているかどうかは Nakama console で確認できます

Usernameは「admin」
Passwordは「password」で入れます

Godot で Nakama Server にアクセスする

こちらのページ

によると、Nakama Server 用の Godotクライアント(ライブラリ)が用意されているのですが、どうもうまくアクセスできませんでした…

公式で Nakama にアクセスするクライアントが用意されている方法がわかりましたら、今後更新していく予定です

Godotからの Nakama Server への接続は、この動画が詳しいので、参考になりそうです。

Steamでゲームを売るときに8つのやるべきこと

Godot Engineで2番目に作ったゲームで 1000ドル (約13万円) の売上を達成した…という reddit の投稿があったのでまとめてみました

見た目もシンプルで、ゲーム内容もほぼ倉庫番…というオールドタイプのゲームにも関わらず、個人開発としてはそれなりの売上を達成しているので、初めてゲームを発売してみよう…と考えている方には参考になる部分も多いかもしれません

Steamでゲームを売るときに8つのやるべきこと

1. プロ並みのバナーアートを作る

Steamではバナーが多くのユーザーが最初に見るものであるため、シンプルな倉庫番のようなレトロなゲームであっても、訴求性のあるバナー画像にするべきとのことです。

例えばSteamのストア内検索で、自分の作っているゲームのジャンルを検索して、他のバナーと比較しても見劣りしないかどうかを確認するのがいいかもしれません。

2. Steamページ(ストアページ)を早めに作成・設定する

個人ゲーム開発者は、ゲームが完成してからストアページを作る傾向がありますがこれは間違いで、早めにストアページを作成しておき、発売までのプロモーション期間を長めにとっておくことで認知度を上げることが大切、とのことです。

というのもゲームが実際に発売されると、発売後1週間でウィッシュリストに入れてくれた人の「約2割」が購入してくれるとの統計があるためです。そしてSteamで販売したゲームは発売後の1週間が売上の大部分を占める傾向があります。

そのため、発売までにウィッシュリストをどれだけ増やせるかが重要となるようです。

3. 遅くとも発売1ヶ月前にプレスリリースを送る

プレスリリース…というと「何をすればいいのかわからないから何もしないでおこう…」としてしまいがちですが、そうすると埋もれるゲームとなりがちです。

ゲームキャストさんがプレスリリースの書き方を説明しているので、やり方がわからない場合はこれを参考にすると良さそうです

 
■STEP 1. プレスリリースの送信日を決める

XXXX年X月○日に、プレスリリースをメディアに送信する日を決める

 
■STEP 2. プレスリリースタイトルを決める

ゲーム内容が端的にわかる文章と、ゲームの特徴を表現できる「キャッチコピー」を決める

 
■STEP 3. メインビジュアル・バナーを作る

ゲーム内容の特徴を表現したキービジュアル、バナーを作る

 
■STEP 4. 序文を作る

メディアに伝えるための事実(あなたの名前、ゲーム配信日、ゲームの特徴、プラットフォームと価格)を書く

 
■STEP 5. 詳細なゲーム内容

ゲーム内容とプレイすることで得られる体験をまとめる

 
■STEP 6. ゲーム要素の説明

ゲームのセールスポイントや面白い要素を100〜200文字、必要であれば画像でまとめる

 

4. 割引を設定する (Steamは割引駆動)

Steamでゲームを売る方法は「割引」。ゲームの売りたい価格を50%OFFになったときの価格を基準として決めると良い、とのことです。

通常、時間と共に段階的に割引率を上げていくのが最適です。

例えば、割引率を33%から、半額、66%、75%へと1年以上かけて徐々に移行していくのがいいでしょう。 ローンチ直後に半額や75%引きといった大きな割引を急いで行うと、定価で購入した顧客に悪い印象を与えるばかりか、製品価値へ悪影響を与えます。

割引のベストプラクティス

ただしローンチ直後に大幅な割引をしてしまうと信用問題となりますので、急いで割引はしないほうが良さそうです。

5. Steamでレビューを多く得られるようにする

Steamでゲームを売るためには、10のレビューを書いてもらうことが重要とのことです。レビューがまったく書かれない場合は、残念ながら失敗である可能性が高そうです。

6 SNSでの口コミを広げる

TwitterやDiscordなどを活用して、コニュニティを広げることが大切となります。

7. コミュニティ内でレビューを書いてくれることを協力してもらう

Steamでゲームを売るためにはレビュー数が重要であるため、それをファンに説明してレビューを書いてもらうように協力を求めます。

8. ゲームイベントに参加・出展する

日本であれば、コミックマーケットやデジゲー博、BitSummitなど、同人・インディー系のイベントに積極的に参加して、プロモーションを行うことが重要となります

Steamでゲームを売る前におさえておきたいポイントBest10

こちらの記事も参考になりそうな部分がいくつかあったので紹介です。

英語で出せないなら出さない方が良いかもしれない

Steamで日英ゲームを売ってみますと、大体英語:日本語の本数割合が7:3くらいです。英語の販促ろくにできてなくてこの数字です。雑に計算して、日本で300本売れたなら世界で+700本、合計1000本売れる可能性を秘めてるわけです。

もっとも上記の数字通りになるとは限りません。海外ウケする/しない絵柄や作風、運や時流もあると思います。とはいえ、文字数が少ないゲームなら英語版を実装してから売るのを強く推奨します。

Steamでゲームを売る前におさえておきたいポイントBest10

Steamを利用している日本人は少ない(人口的にも)ので、Steamで出すなら英語対応はほぼ必須、と考えて良さそうです。

参考

 

2Dゲームアートの選び方

この記事では2Dゲームにおけるアート(グラフィック)の類型について紹介し、それぞれのメリット・デメリットを紹介します。

2Dゲームアートの種類

ピクセルアート

いわゆる「ドット絵」と呼ばれる低解像度のピクセルに色をおいて絵を作るタイプです。

例えばこのようなドット単位で色を置く絵ですね。

通常、低解像度で作られるため、何かを参考に色をおいていけばそれなりの見栄えになるため、「絵が得意でないけれど自分で絵を用意したい」という人にオススメで、またドット絵の素材はフリー・商用ともに多く、それらの素材を利用することで自分で描く手間を減らせるのも良いです。

もちろん、知識がなくても簡単に描けるだけでなく、ちゃんとデッサンなど美術の知識を深め、ピクセルアートを極めると「Hyper Light Drifter」のような美しい世界観のゲームを作ることも可能です。

Hyper Light Drifter (出展:Heart Machine)

またファミコンスーパーファミコンといった時代のゲームは、ほとんどがピクセルアートだったので、その時代のゲームのファンであったり、昔なつかしのレトロな雰囲気を出したい、という場合にもおすすめです。

以下は、ピクセルアートで「背景」を描いてみたいという人のための本です。

パースや光源の処理など、ある程度の絵の知識がある人向けかな…と思いましたが、より高みを目指したい人にはおすすめの本なのではないか、という気がしています。

ベクターアート

複数の点から構成される「線」「曲線」を組み合わせることで絵にするタイプです。

個人的にベクターアートを描くことはないのですが、この形式はUIやロゴを作る場合にとても便利ですね。ベクターアートのメリットとして、ゲームの解像度に依存しないデータを扱えます。

最近のゲームは、解像度が異なるプラットフォームを扱うことが多く、ピクセルデータだとリサイズが少し大変です。その点がベクターデータだと、解像度を自由に変化させてそれに対応するデータを扱うことができます。

プリレンダリング3D

プリレンダリング3Dとは、3Dで作成したデータを事前に画像データにレンダリングして扱うタイプです。

昔のゲームハードでは、リアルタイムで3Dデータを扱うことが難しかったりしたのでよく使われていました。最近でも 3D機能がないゲームエンジンで3D表現を擬似的に行うときに使用されることはありますね。

プリレンダリング3Dとは少し違いますが、3Dモデルの素材を2Dのドット絵風に出力するツールを作って、ドット絵を量産するテクニックもあるようですね。

カットアウトアート

カットアウトは一枚の絵をもとに、キャラクターであれば、各人体のパーツに切り分けて、それぞれを関節でつなぐようにしてアニメーションを行うアートの形式です。

出展:Spine公式ドキュメント

上記アニメーションはよく見ると、各パーツを関節でつなぐことでアニメーションを実現しています

出展:Spine公式ドキュメント

メッシュ変形やIKなどを使用するので、実質3Dモデルと同じ原理ですが、3Dモデルを作るよりはコストは低めです。

この仕組みを1から実装するのは大変なので、通常は「Spine」「Live2D」「DragonBones」などの既存のツールを使って作成します。

どちらかというと2Dアクションゲームでよく使われるアートですが、「Shadowverse」「アイドルマスター シャイニーカラーズ」のようにキャラクターをより魅力的に見せる演出として使用されたり、Switch版の「ファミコン探偵倶楽部」のようにノベルゲームにおけるキャラクターや背景をダイナミックにアニメーションさせるために使われたりしています。

ミニマリストアート

ミニマリストアートとは、極端に記号化・抽象化されたアートです。

スマートフォン向けゲームでよく見かける「棒人間」が出てくるゲームなんかがこれに該当します。

チャリ走シリーズ (出展:スパイシーソフト株式会社)

Nidhogg などもその系統ですね


Nidhogg (出展:Messhof Games

 

モノクロアート

色数を「黒」「白」「グレー」に抑えたアートが特徴です。

LIMBO (出展:Playdead

黒を基調にすることで、暗い世界観やストーリーを表現したり、神秘的な印象を与えることができます。

モノクロアート拡張・ゲームボーイアート

モノクロアートをドット絵で表現して別の色を加えたりすることで、ゲームボーイのような雰囲気があるアートです。

Minit (出展:Devolver Digital Games)

Downwell (出展:Devolver Digital Games)

Minitは白と黒で表現されていますが、Downwellはそれに「赤」が足されています。

ElecHead (出展:生高箸

 

ElecHeadはマリンブルーと白を基調として、電流をオレンジ色で表現しています。

幾何学アート

幾何学的な図形(三角形、四角形、丸など)で表現されたアートです。

 (出展:ABA Games)

古くはABA Games作品、加算合成とグロー処理によるにぎやかな画作りを採用した Geometry Wars で大きく広まった印象です。

Geometry Wars: Retro Evolved (出展:ACTIVISION)

参考