「ゲーム制作」の記事 - Crieit

Cocos Creator 2.xの最新アップデート、Cocos Creator 2.4.10について

2022-12-13T22:54:07+09:00

Cocos Creator 2.4.10をCocos Dashboardからダウンロード

2.4.10では、2.x関連の問題を修正し、エディターとエンジンの安定性を高め、ネイティブ・モバイル・プラットフォーム関連の問題を解決し、全ての2.xユーザーに推奨されるバージョンとなっています。このバージョンはプロジェクトやプラグインの互換性を損なわないので、2.4.7のアップグレード手順を参照してぜひアップデートしてください。

バージョン3.0の正式リリースに向けて、予定通り2022年は重要なバグフィックスを提供し続ける予定です。これらの修正は安定性と使いやすさを中心に最適化されますので、新規ユーザーやプロジェクトについては、3.x で開発することをお勧めします。

インストールに関するご質問は、フォーラム内の開発者ログエリアをご覧ください。

エディター
- リッチテキストを編集した後、タイムラインエディターを終了するときに発生するエラーを修正。

リソースのエクスポート時に、セカンダリフォルダにあるメタファイルの保存場所が正しくないという問題を修正しました。(Finscn氏に感謝)。
フォルダ構成のバンドル優先度プロパティに誤った数値型がある問題を修正(Finscn氏に感謝)。
Mac上のネイティブプラットフォームの構築に必要なPython 2.xのインストールヒントが改善されました。
エディタープロパティパネルのヘルプリンクが機能しない問題を修正しました。

エンジン
- 物理エンジンで、ポリゴンコンポーネントが衝突したときに報告されるエラーを修正(https://github.com/cocos/cocos-engine/pull/10888)

Tweenの停止後に内部データが解放されない問題を修正(https://github.com/cocos/cocos-engine/pull/11360) Finscn氏に感謝します。
Label と particle ノードを無効にすると、Timeline エディタに入った後、コンポーネントの有効状態がおかしくなる問題を修正(https://github.com/cocos/cocos-engine/pull/12384)
Director.EVENT_BEFORE_UPDATE, Director.EVENT_AFTER_UPDATE, Director.EVENT_AFTER_DRAW イベントで、deltaTime パラメータを追加 (https://github.com/cocos/cocos-engine/pull/11359), Finscn.Bhd に感謝します。
MotionStreak 効果の最適化。初期化時のトレイル位置を修正し、1フレームによるトレイル遅延を回避しました。(https://github.com/cocos/cocos-engine/pull/10982)
creator.d.ts のいくつかのインターフェイスの定義を改善しました (https://github.com/cocos/cocos-engine/pull/11981)

ネイティブ
- バックグラウンドに入ったときのオーディオ加速の問題を修正 (https://github.com/cocos/engine-native/pull/4288)

Android プラットフォームで広告にジャンプするときのクラッシュ問題を修正 (https://github.com/cocos/engine-native/pull/4289)
Android 7 バージョン以降、間違った言語が表示される問題を修正 (https://github.com/cocos/engine-native/pull/4290)
ネイティブの WebSocket 呼び出しの Close でゲームがクラッシュする問題を修正 (https://github.com/cocos/engine-native/pull/4291)

Cocos Creator 2.4.10をCocos Dashboardからダウンロード

引用元

Cocos Creator 3.6の主な改善点

2022-11-12T20:20:49+09:00

Cocos Creator 3.0では2Dと3Dを統合しましたが、その後、6つの重要なリリースを重ねてきました。その中には、世界初のHarmonyOSサポートや中国初のNintendo Switchサポートといったプラットフォームサポートの追加、ライティングモデルの最適化やモバイル向け遅延レンダリングパイプラインのサポート、アニメーションシステムMarionetteなどの3D必須機能の追加、開発体験の向上や3Dおよび2Dプロジェクトのパフォーマンス最適化などが含まれています。この2年間の一連のリリースでの進化を見ていただくと「小さな一歩が千里につながる」ということを実感していただけるのではないかと思います。

3.0のマージ以来だと、Cocosチーム内で3.6を最も重要なマイルストーンとして扱ってきました。これまでで最も長いイテレーション・サイクルを設けて、開発効率、ランタイム・パフォーマンス、グラフィカルな表現力において大きく進化しているのがお分かりになるかと思います。

昨年の3.3リリース以降、最も重要な開発メンバーのうち何人かは、3.6ブランチに取り組んできました。このような長い開発サイクルは、何らかの根本的なリファクタリングに必要な場合が多いのです。業界全体にサービスを提供する商用エンジンの特殊性から、常にハードウェアの開発に追随して最高のグラフィック性能に挑戦し、プロジェクトとの互換性や異なるハードウェア環境へのスケーラブルな適応を維持するために、制作サイドの生産性を継続的に向上させる必要があるとされています。

これらの課題は、エンジンが、2Dエンジンから3Dエンジンへの進化のように、時には破壊的に、基礎となるフレームワークの継続的な反復とリファクタリングを必要とすることを意味します。ほとんどの場合、この反復は、3.6に向けた私たちの当初の進展のように、継続的なものです。この進化には多くの共有すべきものがあり、この最新版Cocos Creatorの壮大なハイライトをいくつか紹介したいと思います。私たちの仕事を見ていただくと、エンジン開発の永遠の命題を垣間見ることができるかと思います。それは、ハードウェアの更新やユーザーニーズの変化に対応するためには、絶え間ない自己変革が必要だ、ということです。

注：WindowsプラットフォームはWin32へのパブリッシュをサポートしなくなりました。Win64のみ対応しています。iOSプラットフォームの最小サポートバージョンは、iOS 10.0からiOS 11.0に変更されました（C++ 17を使用するため）。

アップデートに関する全リストと変更ログは、フォーラムのdeveloper notesをご覧ください。

より多くのネイティブ・モジュールでより高いパフォーマンスを

Cocosエンジン・チームは、バージョン3.3のリリース以来、より高いパフォーマンス、互換性、スケーラビリティ、そして生産性を実現するために、コアエンジンのフレームワークを継続的にイテレーションとリファクタリングを行なってきました。

古いプロジェクトとの互換性を維持しつつ、大幅な全体的な改善を達成するために、エンジンチームは複数のフェーズとモジュールでエンジンをリファクタリングするのに1年以上かかりました。

パフォーマンスの大幅な向上とレンダリングの強化をもたらすと同時に、今後のエンジンのさらなる改良のための土台となるものです。

また、これらのネイティブモジュールは、2.xと同レベルの2Dレンダリング性能を達成するという重要なマイルストーンとなります。これは、2.xユーザーが、3Dの追加や継続的な反復の必要性がある場合に、安心して3.xにアップグレードできることを意味しています。2Dのバッチ処理とレンダリング送信処理は、すべてネイティブで行われ、2.xと同等の性能を実現しています。もちろん、Spineのバッチ処理サポートなどの積み残しはありますが、ネイティブの上に3.xの2Dレンダリング性能の上限があることを意味します。

マテリアル、アニメーション、パーティクルのアップグレード

進化という点では、3.6は新しい外観、新しいマテリアルAPI、新しいインポート体験、そしてアニメーション埋め込みプレイヤーやパーティクルノイズマップなどの新機能を提供します。ユーザー視点から見ると、これらはどのような意味を持つのでしょうか。まず、エディタのUIとインタラクションエクスペリエンスの進化が挙げられます。何百もの細かな変更により、開発者の方は、エディタがより良い体験と快適な外観を与えてくれることを直感的に感じられるでしょう。第二に、ライティングモデルとレンダリングアルゴリズムの一連の新機能により、Cocosは最新のモバイルゲームの品質に匹敵するグラフィックを持つゲームを開発できるようになり、特に以下に記したカスケードシャドウと異方性マテリアルを使うと、ゲームをワンランク上のものにできるかと思います。

主なアップデートの詳細

サーフェスシェーダーカスタムマテリアル

サーフェスシェーダは、統一されたレンダリングプロセスと構造を使用しており、ユーザーはクリーンなコードでサーフェスマテリアル情報を作成し、その組み合わせに使用するライティングとシェーディングモデルを指定することができます。旧バージョン（レガシーシェーダー）と比較すると、記述やメンテナンスが簡単で、バージョンの互換性が高く、レンダリングエラーが発生しにくいという利点があります。そして、統一されたフルシーンライティングやDebug Viewのデバッグ機能など、統一された処理で多くの公開機能を得ることができます。

また、Cocos Creatorは、一般的で複雑な様々なマテリアルをユーザーに簡単に拡張できるようにし、Effectコードを自動生成するShader Graphをサポートする予定で、Shader開発者方の効率は大幅に向上できるかと思います。

新しいレンダリングデバッグビュー

この機能は、マテリアル、ライティング、シャドウの表示に関する問題をより迅速に調査するために、様々なカスタム表示モードを提供します。また、特定のシーン情報をより明確に表示することができ、最適化を決定するための参考資料となります。

カスケードシャドウマップ

通常のシャドウマップには重大な欠点があります。投影領域が大きい場合、良好な影効果を得るためには非常に高解像度のシャドウマップテクスチャが必要となり、ハードウェア容量の限界を超えてしまうことがあります。解像度を上げないと、影はギザギザで形のない不鮮明なものになりますが、投影面積を小さくすると、影の距離が非常に短くなり、少し離れたオブジェクトは影が消えてしまいます。影の距離と影の質のバランスを調整するのは大きな頭痛の種で、以前のバージョンでもそうでした。

CSM( Cascade Shadow Map ) は、視野錐台を近景から遠景まで複数のブロックに分割し、近景ブロックの投影面積を小さく、遠景ブロックの投影面積を大きくして、適応型シャドウマップと同等にし、シャドウマップテキストの使用量を数倍に増やしました。近いオブジェクトには非常に精密な影を、視点からの距離が長いオブジェクトにはちょうど良い影の効果を持たせることができるので、開発者は影のパラメータ設定に時間を割く必要がなくなりました。

GGX コンボリューション

直接照明のスペキュラは GGX BRDF モデルを使用しているため、環境照明では、両光源の照明効果を対応させるために、同じ BRDF を使用して球面コンボリューションを行う必要があります。また、粗さの異なる反射情報を対応するミップマップレベルに格納することで、コンボリューション計算により、自動生成ミップマップと比較して、以下の問題を解決することができます。

環境照明のスペキュラのフラッディングやトレーリングが大幅に低減
Substance標準のPBRマテリアルとは異なる効果
直接照明と環境照明のスペキュラの違い

下図をご覧ください
自動生成されたミップマップ

GGXコンボリューションミップマップ

GGXコンボリューションに基づく反射 vs. ダイレクトライティング vs. オートミップマップに基づく反射

異方性照明

サーフェスシェーダの恩恵により、PBRライティングモデルを完全に拡張することができます。v3.6では、等方性、異方性マテリアル、ダイレクトライティングと環境ライティングのライティングモデルが完全にサポートされています。Substance PBRマテリアルライブラリを使用して、ブラッシングされた金属、髪、シルクなどを作成することができます。

エディターUIが全面的にバージョンアップ

V3.6では、エディターUIが一新されました。今回の改訂では、「より協調的な」視覚システム、「より直感的な」視覚フィードバック、「より没入感のある」インタラクション感覚を基本に、UIとインタラクションを全面的に再編成しています。今後も、Cocosのデザイン目標、デザインシステム、デザイン原則に基づいてデザインを標準化し、コアとなるインタラクションやワークフローを最適化するためのアップデートとイテレーションを繰り返していく予定です。

新しいプレビュー・モード

開発効率は、Cocos Creatorが重要視しているコアバリューですが、v3.6ではさらに改善されました。ブラウザでプレビュー "と "シミュレータでプレビュー "に加え、開発者は "エディタでプレビュー "を使ってプロジェクトをプレビューすることができるようになりました。このモードでは、シーンマネージャーが直接コードを実行するため、開発者はリアルタイムでシーンをデバッグすることができます。シームレスなプレビュー体験をもたらす一方で、デバッグの欠点も補うことができます。

この機能は現在実験段階です。ぜひ、ご意見をお聞かせください。今後も、開発効率を重視し、スクリプトコンパイル、プロジェクトデバッグ、ビルドリリースにおけるユーザーエクスペリエンスの向上を継続していきます。

アニメーションクリップにプレイヤーを埋め込む

Animation Editorは、プレイヤーを埋め込む機能を追加しました。開発者は、任意のアニメーションに、他のパーティクルや他のアニメーションを埋め込むことができます。しかも、ビデオ編集ソフトでトラックを編集するような感覚で、持続時間や再生位置などを自由にプログラムすることが可能です。

編集後、埋め込まれたプレーヤーのコンテンツは、このAnimationClipと一緒に再生され、AnimationコンポーネントとAnimation Graphの両方でサポートされます。この機能はFBXからのアニメーションにも対応しており、より柔軟なエフェクトコントロールが可能で、インポートしたアニメーションの再編集が難しいという問題を解決しています。

パーティクルプレイヤーとアニメーションプレイヤーの両方は現在3.6で利用可能で、ラボの設定で有効にすることができます。

多言語サポートが統合されたローカライゼーションエディター

市場の変化に伴い、cocosユーザーのローカライズに対する需要が大幅に増加し、強力なL10nツールが不足しているため、バージョン3.6から公式プラグイン「Localization Editor」が内蔵されました。

その中心的な目的は、高度に自動化されたツールによってユーザーの翻訳効率を向上させ、コードレスでユーザー使用の敷居を下げ、ツールをすぐに使える人なら誰でも使えるようにすることです。

含まれているコア機能は、次のとおりです。

サポート機械翻訳、現在Googleに接続されている、Youdaoの翻訳
翻訳されるべき内容のワン・クリックの抽出のためのサポート
.xls、.xlsx、.csv、.poファイルのバッチインポートおよびエクスポートをサポートします。
サポート多言語の速い切換えおよび下検分

シーンエディタ

シーンエディタに新しいサーフェススナップとバーテックスナップの機能を追加

サーフェススナップ (Ctrl/cmd + Shiftを押したまま)

頂点スナップ (vを押し続ける)

ボックス選択機能をサポートし、複数のオブジェクトを一度に選択することができます。

Marionette アニメーションシステムのアップデート

Animation Graphは編集中のプレビューに対応しました。

アニメーションのステートマシンを編集する際に、リアルタイムにプレビューして遷移やブレンドの結果を確認することができ、修正後にいちいちゲームを起動して結果を確認することなく、素早くデバッグを行うことができます。

アニメーション図が変数とレイヤーの名前変更に対応
アニメーションマップがトランジションラインの順序付けに対応
アニメーション図に「終了開始時間」プロパティが追加され、トランジションの対象アニメーションを指定した位置から再生開始できるようになりました。
アニメーション図で、トランジションを割り込み可能に設定し、指定したトランジションが他のトランジションに割り込まれるようにすることができるようになりました。この機能は、ラボの設定で有効にすることができます。

パーティクルシステムの更新

新しいNoiseモジュールにより、パーティクルに対してより自然で制御可能なランダムモーション効果がもたらされました。

パーティクルシステムのモデルがGPU Instancingに対応し、エミッターのパフォーマンスが向上
パーティクル編集で「元に戻す」操作に対応し、パーティクルエフェクトの作成効率が向上
パーティクルグループのプレビューと制御を階層構造でサポート

デフォルトでモデルを分割しない

CPUで計算するスケルトンアニメーションでは、ユニフォームの数の制限により、ある値を超えるとユニフォームによるスケルトンデータを一度に格納できなくなるため、以前のバージョンではメッシュとボーンを分割することがありました。主にここで自動的に分割されるため、キャラクターモデルの1つが複数の描画コールを占有するというフィードバックをよく受けました。さらに、分割は実行時に行うことができず、前処理しかできないため、我々の分割基準は下位のハードウェアデバイスやドライバ（iPhone 6 WebGL）しか参考にできず、スケルトンの数に対して非常に制限があります。

そこで、Cocos Creator 3.6では、この問題に対して、以下のように戦略的な最適化を行いました。

デフォルトでは、モデルは分割されなくなり、インポートされたモデル・データは変更されません（モデル設定も変更されないままです）。
ボーンの数が実際のランタイムドライバの制限を超えない場合、ユニフォームを使って直接渡されるようになる
ボーン数が制限を超える場合、テクスチャを使用して渡されます。

__ 注意 __ テクスチャを使ってスケルトンアニメーションデータを渡すには、バーテックスシェーダでテクスチャにアクセスする機能が必要です。この機能は OpenGL ES 3.0、WebGL 2.0 で最低限サポートされています。しかし、GL 拡張に依存しているため、OpenGL ES 2.0 と WebGL 1.0 しかサポートしていないデバイスではほぼ 100% カバーされており、互換性の問題を気にする必要はありません。

このオプションは、現在、古いプロジェクトとの互換性を維持するためにのみ残されており、適切な時期に削除が検討される予定です。

メッシュの更新

動的メッシュをサポートし、開発者はAPIを通じて実行時にメッシュデータを更新できるようになりました。

GeometryRendererに新しい曲線タイプSplineを追加（Linear、Bezier、Catmull-Rom曲線に対応）

地形高さブラシのサポート

Cocos Creator 3.6 とCocos Dashboardをいますぐダウンロード

引用元

個人ゲーム開発の壁

2021-12-01T07:00:08+09:00

個人で初めてゲーム開発をしようとしたときに障壁になりそうなものを個人的メモとしてまとめてみます。

障壁になりそうなものについて単に思いついたものを羅列して書いたもので、それぞれの対処法は未調査、または未整理であるため、ここで対処法について詳しくは記述しません。

個人ゲーム開発の障壁となりそうなものは、以下のものです。

ゲームアイディア発想の壁とメンタルブロック
技術選定の壁
プログラミング学習の壁
プログラム設計の壁
デバッグの壁
パフォーマンスチューニングの壁
グラフィックデザインの壁
作曲の壁
物語創作の壁
プロジェクトマネジメントの壁
ゲームデザインの壁
マーケティングの壁

ゲームアイディア発想の壁とメンタルブロック

ゲームを作ろうとしたはいいものの、どのような内容のゲームを作るべきかが思いつかない、という問題です。

すでに作りたい内容が明確に構想できている場合は、ここの問題はスキップされます。

この問題に対して先人らはよく「作りたいもの作ればいいじゃん」とか言いますが、その作りたいものが何かわからない、というような状況がありそうです。さらに「作りたいものが無いなら、そもそもゲーム開発なんてできない／ゲーム作りは向いてない」などと追い打ちをかけられることもあります。

すでに世に出ているゲームの模倣をする、という方法も取れますが、その場合「ゲームアイディアの発想」以外の取り組みの練習にはなりそうですが、肝心の「ゲームアイディア発想」自体はスキップされ、その能力を養う機会を損失しそうです。

また、ゲームアイディアを発想してみたものの、自らの冷静で客観的な評価として否定される（”自分の中のもう一人の自分”や"自分の中の他人”が否定的な評価をささやき、そのゲームを作ることをやめさせる）問題があります。このような「自分の行動を制限しようとする思考」は、通称「メンタルブロック」と呼ばれています。（もう一人の自分が「そんなゲーム作ってどうするんだ？」「どのゲームのどこがおもしろいんだ？」などとささやいてくる）

技術選定の壁

ゲーム開発の技術的な知識がほとんど無い状態だと、何を使ってゲーム開発すべきかがわからない場合があります。

この場合、Webで情報を検索してみたり、質問サイトで相談する、という方法がとれます。そして、（下書き執筆開始の）2020年12月執筆時点では、個人ゲーム開発で使用する技術としておそらく一番多くおすすめされるものが Unity というゲームエンジン兼各種エディター、ツールで、次点で Unreal Engine がおすすめされるでしょう。

たまに素のプログラミング言語（とその処理系）から、Unity のようなツール群を使わずにゲーム開発をしたい、という（学習者の技術投資の価値観としての）ケースがありますが、その場合は、各種プログラミング言語とその処理系、実行環境との相性などの特徴から選定を行う必要があるため、迷いが発生しやすいです。

昨今、ゲーム開発企業の現場から「Unityの表面的な部分しか使えないより、もっと奥深い部分を理解して使いこなせる人材がほしい」という声も聞かれるため、もし個人でゲームを作ろうとする理由が就職のためである場合に、Unity 以外の選択肢を選ぼうとする理由が生まれる可能性はあります。

「Unity でも深く学べば、奥深い仕組みの部分も学べるんじゃないか」という意見もありそうですが、Unity が持つ機能の一部はブラックボックス（中身が見えないもの）であり、むしろ、「奥深く中身を見なくてもゲーム開発ができるようにするためのツール」であるため、やはり、Unity についてのみ学習することは、その奥深い、コンピューターに近い部分の仕組みや、レンダリングの仕組みや手法、その特性などを学ぶ機会を失う可能性が否めません。

プログラミング学習の壁

多くの開発環境では、プログラミング言語を駆使する必要があるため、プログラミング言語についての学習を行う必要があります。しかし、この段階でつまづくケースがあります。（Unity では C# というプログラミング言語を駆使する必要があります）

多くの場合、学習の順序、段階をスキップしているがゆえに起こる問題が多いように思います。例えば、プログラミング言語の文法の学習をスキップして、作ろうとしているゲームの機能の実装方法を調べて（「〇〇の作り方」などと検索して）得られたプログラムの断片をコピーして作ろうとすると（いわゆる「コピペプログラミング」と呼ばれる方法）、コンパイルエラーや意図しない動作への自力での対処が難しく、このような状況に陥ると「ゲーム開発は難しい」「わからない」などの感想を強く持ち、ゲーム開発をあきらめる理由が強化されます。

かと言って、プログラミング言語の文法をいちからじっくり学ぶ方法をとっても、いつまで経っても動くゲームを作ることができず、学習が飽きてしまうという問題が指摘されることがあります。そのため「プログラミング言語の学習と、ゲームの実装の両方を、ほどほどにバランスよく進める」という助言がされることもありますが、どうやったらほどほどにバランスが良いのかの指標が具体的に提示されることは少ないため、なかなか迷いやすい部分にはなりそうです。

「自分は今、どの部分の知識が足りていないがゆえに、今の問題に直面しているのか」が可視化されれば問題に対処しやすいですが、現時点ではそれを可視化するための良い方法が普及しているとは言い難いため、救われない人が多くいるのではないかと想像します。

学習のガイド役となるような（いわゆるメンター的な）存在が身近にいて、学習をガイドしてくれるなら救いの道があります。このガイド役は「学習者がいま問題に直面しているのは、どの部分の知識が足りていないからなのか」について分析（広義のカウンセリング）をして、どの部分の知識が足りていないのかを知り、その不足を補うための（"処方箋"のような）具体的な対処法を提示する必要があります。

この分析をせずに無理に助言をしようとする場合、その多くは「説教」のようになってしまうでしょう。

プログラム設計の壁

小規模のゲーム開発であれば、プログラム設計が雑でも”チカラ技"で完成させることができるかもしれないですが、中規模以上のゲーム開発となると、雑なプログラム設計では、ちょっとした機能追加や修正作業でもプログラムを変更する箇所が多すぎたり、データとロジックの不整合などによってプログラムのうまい変更方法を思いつけなくなったり（この場合は、たいてい作り直すのが早い）、プログラムの変更が意図しない機能に影響を与えて不具合を生んだり、などのような問題が起きます。

この分野に関しては「プログラムの一般化／抽象化／モデル化」「高凝集化」「疎結合」「関心の分離」「オブジェクト指向設計」などのキーワードで語られることがあり、高度なものになると「MVC」「MVVM」「双方向データフロー」「単方向データフロー」「クリーンアーキテクチャ」「リアクティブプログラミング」「ドメイン駆動開発」などのソフトウェアアーキテクチャの分野で説明されることがあります。

これらの分野は、自主的かつ積極的にプログラミング関連の情報を収集しているか、学習のガイド役の人がガイドをしない限り、学習しようとする機会が生まれないかもしれないです。

デバッグの壁

プログラミング初学者が、コンパイルエラー、実行時エラー、意図しない動作に遭遇したときの対処方法を積極的に学ぶ機会は少ないかもしれません。

コンパイルエラー、実行時エラーのエラー文の意味を解読するためにはプログラミング言語の文法を理解している必要があるため、そのエラーの対象となる文法の学習をスキップしている場合は、その解読ができません。（エラー文で検索して出てきた対処法を見よう見まねで組み込んでも、それは付け焼刃的なものになるでしょう）

また、実行時エラーや意図しない動作に対処する場合、何らかのデバッグテクニックや、いわゆる「デバッガー」というツールを駆使して、問題の原因を特定する必要があります。しかし、プログラミング初学者は「実行時エラーや意図しない動作の原因を特定するためにはデバッガーを使えば良い」ということ自体を知っていないケースがあり、たまたまデバッグ方法について上手に説明している教材に巡り合えたか、良いガイドがされた場合だけに成長が約束されます。

パフォーマンスチューニングの壁

ゲームを作ってはみたものの、メモリ使用量が多すぎたり、処理に時間がかかりすぎてフレームレートが低くなったりなどの問題が起こることがあります。

このようなとき、いわゆる「プロファイラー」と呼ばれるようなツールを使ってボトルネックを発見し、そのボトルネックを解消させる必要があります。

メモリ使用量や実行速度の問題が起きた時に「プロファイラーを使ってボトルネックを見つけて解消する」という方法を自体を知るには、かなりプログラミングについて調査、学習をしているか、良いガイドが必要になります。

グラフィックデザインの壁

自作でゲームを作るからには、グラフィック素材についても自作したい、と思うケースがあります。ゲームに近いグラフィックデザインに関する理論が確立されているのかどうかは筆者はわかりません。

お金に余裕があれば、上手な人に頼んだり、有償の素材を購入するという対処ができます。

フリー素材を使うという方法もあります。

作曲の壁

自作でゲームを作るからには、音楽素材（または効果音）についても自作したい、と思うケースがあります。音楽理論は長い歴史で確立されているので、学習しやすい分野ではあるかもしれないです。

お金に余裕があれば、上手な人に頼んだり、有償の素材を購入するという対処ができます。

フリー素材を使うという方法もあります。

物語創作の壁

物語要素を含めたゲームを作る場合、その物語を作る必要があります。

物語要素を含むゲーム作品では、その物語の内容はオリジナルである必要があるため、グラフィック素材や音楽のようにすでに提供されている素材を使う、というような方法はとれません。

良い物語を作るため方法論は長い歴史の中で割と確立されているようで、関連した書籍が多く出版されている印象がありますが、その書籍を購入するための資金と、その書籍を用いた学習をするための時間と心的リソースは必要になります。

プロジェクトマネジメントの壁

中規模以上のゲームを開発するような場合、プロジェクト管理を上手くやらなければ以下のような問題が起こります。

次に取り組むべき作業が何かわからない
どこまで作業をすれば良いのかわからない
いつ完成するのか見えない
今どのくらい作業が進んでいるのかわからない（残りの作業がどのくらいあるのかわからない）
仕様の何を直せばいいのかわからない（目指す品質・優先しない品質が何かわからない）

いわゆる「創作のモチベーション維持」がうまくできていない場合は、ここがうまくできていない可能性があります。

ゲームデザインの壁

思い描いたゲームの試作してみたものの、「思っていたものと違う」「どうも面白くない」というような場合はゲームの内容を上手く修正して良い内容に変えていく必要がありますが、具体的に何をどう変えたら良くなるのかがわからない場合があります。

ゲームの内容の良さに影響する要素は複数ありますが、それぞれで良さを生むようにするための方法はそれぞれで専門性があります。例えば、ゲームの競技ルールが良くないがためにゲーム展開が盛り上がりに欠けるようになってしまったり、視覚効果が貧弱でゲームプレイで高揚感が得られにくい、などあります。競技デザインと視覚効果デザインは専門性が異なります。

マーケティングの壁

これはすでにゲームが完成したあとの話になるが、「作ったゲームが知れ渡らない」「作ったゲームが良い評価を受けない」というような場合、マーケティングの視点でゲームの内容を見直す必要が出てくる。

【1週間】Web ゲームを爆速で開発するために実践したこと🐧個人開発向け

2020-06-23T09:37:52+09:00

(内心)
作ったゲームを沢山の人に触ってもらってリアクションが欲しいなぁ～
そうだ、記事投稿して宣伝しよう！

といった下心で書いた記事です。すみませんでした遊んでください😆

Web Game 処女作🎉シンプルでストレス発散になるゲームが爆誕！敵さんを吹っ飛ばして 1,000 G 以上を目指してみてね😆https://t.co/h8w574aGGQ★アドバイス急募★『こうしたらもっと面白くなる』など、ご意見ご感想を頂けると嬉しいっす(〃´∪｀〃)ゞ#今日の積み上げ #100DaysOfCode DAY 21 pic.twitter.com/HJvFj87zTf
— hikaru🐧#100DaysOfCode! (@hikaru_firecamp) June 17, 2020

ペンギンがサメさんを倒すゲーム
敵さんを吹っ飛ばして 1,000 G 以上を目指してみてね😆
https://games.westa.io/

0⃣ 結論 / 爆速で開発するために実践したこと

１週間のカウントダウンタイマーを設置する
適当な企画書を作って全体を把握しならが作業する
新しいことは１個までに制限して知っているものを使う
こだわりたい部分を絞り他を捨てる覚悟を持つ

1️⃣ この記事の対象読者

この記事では１週間で Web ゲームを作る為に何を考え何をしたのかを書きました。
以下に当てはまる人達に参考になれば嬉しいです。

好きなことへのこだわりが強くいつまでも作品が完成しない人
いつもダラダラ期限を伸ばしてしまう人
このゲームがどんなライブラリ使っているか知りたい人
奇特な人

2️⃣ なぜ１週間なの？

個人開発の一番の敵っていかにモチベーションを保つかだと思いませんか？

私の場合１ヶ月もたてば他に興味あることが出てきてしまうのでモチベーションが移ってしまいます。
でも、１週間なら全力で頑張れるちょうどよい長さかな～と考えました。

(それと、１週間ならクオリティ低くても言い訳になるかなと)

3⃣ １週間という短い期間で終わらせるために意識したこと

(1) １週間のカウントダウンタイマーを設置する

いつもズルズル伸ばしてしまう癖があるので Twitter で公開日を宣言しました。
そして公開日までのカウントダウンタイマーを常に目に入る位置に設置しておきました。

次に出す Web アプリのリリース日を 6/17 12:00 頃に決めました🎉メリハリ付けるために中途半端でもこのタイミングで出します写真はちょうどいいカウントダウンタイマーが無かったので作ってみました▪コードはこちらhttps://t.co/HiGjiROP4R(8,9行目を編集すれば自分用に使えるよ！) pic.twitter.com/HnjXxktDLb
— hikaru🐧#100DaysOfCode! (@hikaru_firecamp) June 8, 2020

このカウントダウンタイマー、すっごく効果があったように思います。度々目に入るので程よい緊張感と無機質な圧力をくれます。
さらにシレっと周囲の人たちに公開日を宣言できるのでかなりお勧めです。

⚠ 補足 ⚠
さも予定を守ったように言ってますが結局半日ほど遅く公開してしまいました
ほんとすみませんでした 😗

(2) 適当な企画書を作って全体を把握しならが作業する

企画書などが無い状態でコーディングすると目に付いた場所から手を付けてしまいがちで視野が局所的になりやすく作業の優先度決めが難しくなります。

簡単なものでも全体像を把握できるものがあると、次にどの部分を実装するか考えるときに『最低でもここを実装しないとだから優先度高めで』みたいなスケジュール管理が容易になります。

今回は以下の様な簡易仕様書をあらかじめ書いておりました。

これから作るミニゲームの簡易仕様書！よくあるクリックゲームですが、ちゃんと作りきれるか不安😇１週間がんばります〜(あ、奇しくも一人 web1week みたいになってる)全然関係ないけど最近 iPad でお絵描きの練習始めました！スマブラやったことあればピンとくるはず😎 pic.twitter.com/oVo5xAUeBe
— hikaru🐧#100DaysOfCode! (@hikaru_firecamp) June 9, 2020

これのおかげで実装段階での仕様変更が減り、一直線にゴールに向かって実装できるので結構大切なものだと思います。

(3) 新しいことは１個までに制限して知っているものを使う

初めて使う道具が多いと勉強することが増えたり些細なことにはまったりして時間を消費しがちなので、使い慣れた開発環境と使った事のあるライブラリを中心に選定しました。

使い慣れたもの

VS-Code ... 開発環境
TypeScript ... 開発言語
UIKit ... UI コンポーネント

以前から実験レベルで遊んでいたもの

Three.js ... 3D 描画エンジン
Cannon.js ... 3D 物理エンジン

初めて使うもの

Audio API ... BGM や効果音の再生

今回は遊べる Web ゲームを短期間で作ることが目的だったので冒険をしない制約を設けましたが、完成度が低くても未知なる技術を沢山学びたいならどんどん新しい技術を使ってみたらよいと思います。

目的次第でやり方を臨機応変にすることが大事なのかなと😎

(4) こだわりたい部分を絞り他を捨てる覚悟を持つ

こだわりが強いと味のあるイイものができるけど、その代わり完成が遅くなる傾向にあると思います。

今回は『ローポリキャラ達が物理演算で予想外の挙動をする』部分だけこだわりましたが、操作 UI の見た目などはブラウザ標準のプログレスバーを使っていたりと大部分はかなり適当です。

個人的にはゲームの中にブラウザの DOM を混ぜることに違和感とアレルギーを感じるのですが『こだわる部分を絞って他は適当』と大胆に割り切っちゃいました。

他にも、ペンギン/サメ/コイン/木の当たり判定はすべて立方体(正六面体)で手抜きをしましたが、これは予想に反して『サメさんやコインが地面に刺さってる』ように見えたり『木々があらぶってる』感じになったりヘンテコな世界観の演出に一役買ったように思います。

4⃣ おまけ: 実装 Tips

唐突なおまけの実装 Tips です。

(1) Cannon.js / サメさんの Z 位置(奥行)を固定

Cannon.js は 3 次元物理演算なので XYZ 軸分の動きがあるのですが、サメさん(敵)に関しては奥行方向に動かれると攻撃を当てられなくなるので Z 軸を固定しています。

// CannonJs: サメさんの物理演算用の剛体を生成
const sharkBody = new CANNON.Body({ ＜省略＞ });

// ThreeJs: アニメーションループを開始
renderer.setAnimationLoop(() => {
    // CannonJs: 1フレーム分の物理演算を実行
    world.step(＜省略＞);

    // ★★ サメさんのZ位置を固定する ★★
    sharkBody.position.set(
        sharkBody.position.x,
        sharkBody.position.y,
        0); // Z軸を0に変更
});

(2) Cannon.js / 摩擦設定・反発設定

初期値だとほとんど滑ることは無く、滑らせた方が面白そうだったので摩擦と反発の設定をいじっています。

モデルごとに摩擦係数や反発係数を設定できれば直感的だったのですが、Cannon.js では『モデル１とモデル２に対しての摩擦・反発を設定』といった具合に設定が必要でした。

// 
// 物理演算ワールドを初期化
// 

const world = new CANNON.World();
world.gravity.set(0, -9.82, 0); // m/s²

const floorBodyMaterial = new CANNON.Material(`FloorModel`);
const penguinBodyMaterial = new CANNON.Material(`PenguinModel`);
const sharkBodyMaterial = new CANNON.Material(`SharkModel`);

// 摩擦反発設定: 床とペンギン
world.addContactMaterial(new CANNON.ContactMaterial(
    floorBodyMaterial,
    penguinBodyMaterial,
    {
        friction: 0.01, // 摩擦設定 (ペンギンが床を滑るように)
        restitution: 0.8, // 反発設定
    }
));

// 摩擦反発設定: 床とサメ
world.addContactMaterial(new CANNON.ContactMaterial(
    floorBodyMaterial,
    sharkBodyMaterial,
    {
        friction: 0.05, // 摩擦設定
        restitution: 0.3, // 反発設定
        contactEquationStiffness: 1e8,
        contactEquationRelaxation: 3,
    }
));

// 摩擦反発設定: ペンギンとサメ
world.addContactMaterial(new CANNON.ContactMaterial(
    penguinBodyMaterial,
    sharkBodyMaterial,
    {
        friction: 0.01, // 摩擦設定
        restitution: 2.0, // 反発設定 (攻撃を受けたサメが吹っ飛びやすいように)
    }
));

(3) Three.js / 同じモデルは使いまわして効率化

今回ゲーム内では同じモデルが大量に出現します。その際に毎回モデルをロードしていると実行効率が悪いので、モデル管理クラスが必要になります。

こういった目的の管理クラス系にはシングルトン実装が最適かと思いますが、TypeScript では module を使うと簡単にシングルトン実装が可能です。

/** モデル名の型定義 */
export type ModelName = `PENGUIN` | `SHARK` | `TREE` | `COIN`;

/** 
 * ゲーム内のモデルを管理するモジュール
 *　 シングルトン実装
 * 　モデルをあらかじめロードして、ロード済みのモデルを使いまわすことで効率化
 */
export module ModelManager {
    /** ロード済みのモデルを保持 */
    const modelMap = new Map();

    /** 各種モデルをロードする */
    export async function load() {
        await loadModel(`PENGUIN`, `models/PenguinJumping.glb`);
        await loadModel(`SHARK`, `models/Shark.glb`);
        await loadModel(`TREE`, `models/Tree.glb`);
        await loadModel(`COIN`, `models/Coin.glb`);
    }

    /** モデルを複製して取得する */
    export function getModel(modelName: ModelName) {
        return modelMap.get(modelName)!.clone();
    }

    /** ロード済みモデルを開放する */
    export function dispose() {
        // ThreeJs: ロードしたモデルをすべて解放
        modelMap.forEach((obj3D, key) => {
            GameUtils.disposeObject3D(obj3D);
        });
    }

    async function loadModel(modelName: ModelName, path: string) {
        // ThreeJs: モデル読み込み
        const obj3D = await GameUtils.loadGltfModel(path);

        // リストに追加
        modelMap.set(modelName, obj3D);
    }
}

使い方

// あらかじめすべてのモデルをロードする
await ModelManager.load();

// ペンギンモデルを取得する (内部的にはロード済みのモデルを複製しているので効率的)
const penguin1 = ModelManager.getModel(`PENGUIN`);
const penguin2 = ModelManager.getModel(`PENGUIN`);
const penguin3 = ModelManager.getModel(`PENGUIN`);

最後に

ゲーム開発中に Twitter でいいねやコメントなどでリアクションをくれた方、開発中のゲームを試してヒントをくれた友人方、本当にありがとうございました。
大変励みになりモチベーションになりました、重ねてお礼申し上げます😆

あと、ここまで読んでまだプレイしていない人！！
↓ やってからリアクションをクレクレ厨😗

ペンギンがサメさんを倒すゲーム
敵さんを吹っ飛ばして 1,000 G 以上を目指してみてね😆
https://games.westa.io/

P.S. crieit.net で初カノニカル投稿してみました🎉これ書く側としてはイイ仕組みですね

スマホ向けゲームを作る時に何を使うと良いのかを考察

2020-06-11T11:24:15+09:00

スマホでマルチプラットフォームのゲームを作る際にどういったソフトウェアを使えばいいかを検討したのでその考察のメモ。2020/6時点。

ちなみにどの点を考えたかというと下記あたり。

ライトなゲームの作りやすさ
AdMob、Analyticsの導入のしやすさ
ライセンス料（だいぶ前に調べた知識なので今は違っているかもしれない）

ゲームエンジン

ゲームを作るためのソフトウェアを使う場合。可能であればこれが良いと思う。

Unity

これがなんでも揃っててベストだと思う。

ただし一点懸念として、ライセンス料金の高さがある。とくに何もなければ気にする必要はないと思うが、前年の売上が20万ドル、つまり2千万円くらいを超えてくると毎月の高いライセンス料を支払わなければならない。そのため個人開発としてはちょっと厳しい。

間違っていたら指摘してほしいが、利益ではなくてあくまでも売上。たとえ手元にお金が一銭も残っていなかったとしてもお金のやり取りの累計がそこに達してしまうとダメ。例えば会社を運営していたり、依頼を受けて他の人に発注、とかやっていると自分のところにお金が残らなくてもライセンス料を払わなければならない。もちろんゲーム自体でそれだけ売り上げていれば問題ないと思うが、これから始めようという人には厳しい。法人の売上はあるけど個人としてやるから良いんじゃない？　というのもダメだった気がする。

Unreal Engine

これもいい。しかしiOSのAdMobの利用方法が見つからなかった。もし現状なかったり独自に作る必要があるのだとするとさすがにちょっと厳しい。

一応有料だがAdMobを使うためのパッケージが販売されていたが試してはいないのでわからない。買い切りだと思うのでいい感じに動くのであればいいと思うが謎。

AdMobの調査の時点で疲れてしまったのでAnalyticsは調べていない。

Unreal Engineだとガチのゲームを作るというイメージが強いので、多分広告でかせぐというよりはちゃんと課金で稼ぐパターンの方が多いという感じだろうか。あとはモバイル向けというよりはSteam向けなど。何にしろその部分の心もとなさがある。コア部分であるゲームのエンジンとしてはかなりいいとは思うのだが。広告は使わない、という場合はわりとこれ一択になる可能性もありそう。でもリワード広告も使いたいと思うんだけど…。

ライセンス料は確かアプリごとで、かつかなり売り上げていないと発生しないので問題なかった気がする。

Godot

OSSのゲームエンジン。3Dもいけるし僕もこれでアプリをリリースしたことがある。ライセンス料も無い。

AdMobは使える。しかしAnalyticsのiOS用のものが無かった。そこだけがネック。

Androidの方は最新バージョンでモジュールを追加しやすくなったが、iOS側は自分でビルドなどしないといけないためそのあたりの理解は必要。

iOSのAnalyticsが使えれば最高だと思うんだけど……。まあそこだけ諦めればあとは十分ではある。

追記）
redditで聞いたらGDScriptで自分でAPI使ってクライアント作ればいいよ、とのことだった。試してみる。

ゲーム以外のフレームワーク

ゲーム以外のフレームワークでもゲームが作れる。ただし専用のエディタなどがないので開発効率に響く場合などがあるのではないかと思う。実際に後述のreact-three-fiberでも、シミュレータはきついから実機で確認したほうがいい、という記述があったりする。Webでも試せればそれでも良いかもしれないが、何にしろ快適に開発を行うためにはちょっと環境構築で色々試行錯誤は必要そうな気がする。

React Native

前述の問題はあるが、AdMobもAnalyticsもあるしゲームエンジン（react-native-game-engine）や3Dエンジン（react-three-fiber）などもあるので、スムーズに開発できればかなり良さそう。

Flutter

Flutterはまだゲームフレームワークがそれほど発展していなさそう。いちおうflameという2Dゲームのパッケージがあるので2Dゲームについては結構いけたりするんだろうか。

AdMobやAnalyticsもある。ただしフレームワークの起動方法によっては普通に使えない可能性もありそう？

まとめ

ということで色々調べてみたが、どれも一長一短っぽい。作りやすさ、ゲームの規模、どうやって売上を出すか、によって最適なものは随時変わっていきそうな気がする。

【個人制作者向けすぐ出来る】結局ゲームエフェクトはデカさイズ正義 by 大学生ゲーム制作者

2019-07-01T12:38:53+09:00

2019/6/2

おはようございます。

エンジニアのはずがここ1ヶ月何故かデザインばかりしている、大学生ゲーム制作者の村人Uです。

ゲームデザインに関する記事はいくつか投稿してきましたが、今日もゲームデザインのお話です。

実験と結果からどんどん内容をアップデートしていきます。

昨日は制作中のゲームで、ワザを発動する時のエフェクトについて数時間友達とあーだこーだやっていました。

そして、色々試してみてこれを抑えていればゲームのデザインのレベルが一つ上がるんじゃないかなという事を見つけたので共有しておきます。

派手なエフェクトはとにかくでかい

色々試したのですが、もっと派手なエフェクトを作りたい時には、とにかくデカくしてみるのが効果的でした。

見にくいですが、下の動画は元々のエフェクトは同じでサイズ感を変えたものです。
(ワザを使った時にでる円状のエフェクトの話です)

小さいバージョン

中くらいバージョン

大きいバージョン

最後はもうカメラ外からエフェクトが出てきちゃってます。

キャラクターのサイズと、エフェクトのサイズを冷静になって良く見てください。

頭悪いくらいエフェクトがでかいです。

そりゃあもう、キャラクターの8倍デカイです。

キャラクターのエフェクトを考えているのにこのサイズにするのは流石にバカだと思ったのですが、これが意外にバカではなくて驚きました。

どうやら、ゲームエフェクトはデカさが大事なようです。

フェードインを忘れるな

バカでかいエフェクトを作って、派手にはなったものの、どうにもダサさが抜けませんでした。

大きなエフェクトに目を奪われてそのエフェクトを冷静になってみた時に、どうやらダサく感じるようです。

この対策としては、フェードインをいれるというのが一番効果的でした。

最初は透明にしておいて、徐々に透明じゃなくしていくあれです。

エフェクトがでかいうちは透明にしておく事で、エフェクトに目を奪われる事がなくなります。

gifだとめちゃくちゃ分かりにくいですが、↓はフェードインを加えたものの比較です。

フェードインなし

フェードインあり

同様に、フェードアウトも加えた方が良さげでしたが、フェードイン程の効果は無さそうでした。

まとめ

ゲームエフェクトを派手にする要は次の2つでした。

とにかくデカくする
フェードインをいれる

サイズを変えて、透明度を変えるだけなので割とすぐに試せるかなぁと思います。

もしゲームエフェクトで何か違うと感じたら、まずはこの2つを変えてみるのは効果的だと思います。

現場からは以上でーす。

【ブラッシュアップ】今あるものをもっと良くするには違和感に気づけ by 大学生ゲーム制作者

2019-06-16T20:49:52+09:00

おはようございます。

最近なぜかずっと眠くてテンションが上がらないので、外を全力疾走中の大学生ゲーム制作者の村人Uです。

少なくとも今は目が覚めています。

さて。

僕はゲーム制作をしているのですが、最近ゲームの "見た目" に力を入れ始めました。

そこで思ったのですが、今ある見た目をもっと良くするためには違和感に気づく事が鍵だと感じました。

↓は作っているゲームのメニュー画面です。

どうですか、素人が作った画面ですよ、凄くないですか。(圧)

事実、これを僕の周りの人(別にデザインに詳しいわけではない)に見せると結構良い反応が返ってきました。

ただ、僕はずっと違和感がありました。

何かが違う。

そこで、数多のスマホゲーム、ドット絵の画像を見まくっているとある事に気が付きました。

『ボタンがダサい』

正直これは薄々分かっていたので、友達(デザインは素人)にお願いしてすぐに他のパターンを試してみました。

結果少し良くなり、友達的には２番目のやつが良いと言ってたのですが、でもやっぱり僕はどれも違和感がありました。

そして再び数多のスマホゲーム、ドット絵の画像を300%拡大して見まくっているとある事に気が付きました。

『ボタンに立体感がない』

これまた速攻で友達(デザイン素人)にお願いをして、ボタンに影とハイライトを入れてもらいました。

するとどうでしょう、めちゃいい感じになりました。

ボタンらしくないのは押せそうに無いからだったんです。

デザイナーさんが喜んでいる中、僕はまだ違和感がありました...。

そして再び数多のスマホゲーム、ドット絵の画像を夢に出るまで見まくっているとある事に気が付きました。

『ボタンがでかい』

全体的に見たときにボタンのサイズが大きすぎたんです。

そこで、これまた速攻で友達(デザ素人)にお願いして画像を小さくしてもらいました。

さらに、ボタンがもっと画面の端に寄るべきだという事にも気づいたので配置を変えました。

どうですか。良くないですか。(圧

少なくとも最初よりは良いですよね。

これは一例ですが、こんな感じで今あるものをもっと良くするときには違和感に気づくのが大切だと思います。

そしてこの違和感を感じられるようになるには、ひたすらに良いものを見て経験を肥やすしか無いかなぁというのが今の結論です。

とにかく良いものを知って、頭に刷り込ませておくとこういう場で違和感に気づけるのだと思います。

これは、絵に限らずだと思います。

今ちょうど、僕はゲームのプレイ画面に違和感を覚えています。

この違和感が何かまだ分からないので、色んなものをインプットして違和感の正体を見つけてみようと思います。

https://twitter.com/werquest/status/1132967464818528261
`

#ゲーム制作 #Unity
試しに動画撮ってみた。楽しい。 pic.twitter.com/vRNoLGpRU5
— QuestGames@大学生がゲーム制作に挑戦するようです。 (@werquest) 2019年5月27日

違和感に気づいた方がいたら、御一報ください。

ここのコメント欄でもTwitterでも大歓迎です。

QuestGames@大学生がゲーム制作に挑戦するようです。 (@werquest) | Twitter

現場からは以上でーす。ではでは。

【Unity】大学生でも出来る全部無料のゲーム開発環境（おすすめアセットなど） by 大学生ゲーム制作者

2019-06-12T19:42:11+09:00

2019/5/20

おはようございます。

ゲーム作りも面白いけど、機械学習とか極めてみるのも面白そうだなあと思っている、大学生ゲーム制作者の村人Uです。

VRとかMRもいいですね。

さて、今日はゲームの開発環境（基本的にUnityのアセット）について書こうと思います。

開発環境といっても、ゲームを作る為に使っているツールの話で、開発者向けの内容になってしまいます。

実はゲーム開発を開始した段階で、一度こういう記事は書いたのですが、結構変化があったのでその辺についても触れながら、今の開発環境を改めて書き直そうと思います。

無料かつ個人（チーム）でのゲーム開発環境

ちなみに、紹介するものは全部無料で利用出来ます。

Unity

ゲーム制作者お馴染みのゲームエンジン。

これが無ければ始まらない。

これ一つでPCゲームから、スマホゲーム、VRまで作る事が出来てしまいます。

↑ゲーム起動時にこういうの見た事ないですか？

使った事はないのですが、対抗馬にUnrealEngineというのがあって、イメージとしてはUnrealEngineは3Dゲームや映像制作に強く、プログラミングがそこまでできなくても扱えます。

Unityは2Dでも3Dでも幅広く扱えて、頑張れば何でも出来るというイメージです。

また、ネットの情報量はUnityの方が多いような気がします。

Unityについては↓の記事が分かりやすいです。

今日からはじめるUnity - Qiita

Photon2

Unityのアセットの1つです。

Unityに入れて使います。

昔は以下の機能が別々に分けられていたのですが、今は1つのPhoton2にまとめられています。

Photon Unity Networking (PUN)

オンライン通信を行う為に使用します。

マルチプレイや通信対戦が可能になります。

今回はリアルタイム通信で位置同期やダメージの同期、マッチングなどに使っています。

ラグが大きいかなぁと心配していたのですが、頑張れば白猫プロジェクトくらいのゲームが作れると思います。

PUN2 - FREE AssetStore

PhotonChat

PUNは常に様々な通信が必要な場合に使いますが、文字のやりとりや数回程度の通信であればPhotonChatが利用できます。

PUNでもチャット機能は実装できるのですが、PhotonChatはチャットに特化していてPhoton2より楽に実装出来ます。

また、荒野行動のようにフレンドにリアルタイムでチーム招待を送る機能などは、このPhotonChatで行う事が出来ます。

Photon2については↓の記事が分かりやすいです。

PUN2で始めるオンラインゲーム開発入門【その１】 - Unity Connect

PlayFab

サーバーにデータを置きたい場合などに利用します。

俗にmBaaSと呼ばれるサービスです。

所持コイン、魔法石、フレンド、プレイ時間などのユーザーデータをサーバーで管理する事ができます。

Unityとの相性も良いです。

ただし、ネットにはほぼ英語の情報しかないです。

僕の知っている限り、このようなサービスは他にもNifty Cloud Mobile Backend (NCMB)やfirebaseなどがあります。

僕も初めはNCMBを使っていたのですが、PlayFabに移行しました。

理由は後ほど説明しますが、初心者の方にはNCMBをおすすめします。

PlayFabについては、↓の記事が導入を書いてくれています。

PlayFabでUnityを動かしてみる -その1下準備編- - Qiita

↓の記事では実際に使ってみた感想やまとめを書きました。

無料で使えるmBaaSのPlayFabをプレイヤーデータ管理に使ってみた by 大学生ゲーム制作者

こちらもUnityのアセットです。

ツイッターやLineなどのSNSと連携したい時に使います。

ゲーム内からSNSのアプリを起動し、用意した定型文やスクリーンショットの投稿をしてもらう事が出来ます。

しかし、SNS連携はURL Schemeを利用する方法もあり、ツイッターかLineであればこのURL Schemeを利用する方が簡単です。

このSocialConnectorはその他のSNSにも幅広く対応出来るというのが魅力かなぁと思っています。

SocialConnectorについては↓の記事が分かりやすいです。

【Unity】Social ConnectorでTwitterにスクショを投稿する

Nifty Cloud Mobile Backend (NCMB)

↑で説明したPlayFabのように、サーバーでデータを管理する時に使います。

サーバーにデータを保存、サーバーからデータを取得などの機能があります。

また、Unityとの相性も良いです。

PlayFabと違うのは、機能の数と無料枠です。

PlayFabはフレンド機能、グループ機能、ログイン機能、アイテム機能などが事前に備わっている、要はゲーム特化になっているのに対し、

NCMBは、エクセルのようなマスがあるだけの、シンプルで幅広い用途で利用できるのが特徴です。

また、↓の記事でも書きましたが、NCMBは無料枠が少し足りない可能性があります。

対してPlayFabはNCMBのような制限は無いので、ユーザーの数が増えたとしても問題ありません。

Unityでリアルタイムフレンド申請の実装方法を考えた話 by 大学生ゲーム制作者

ただ、PlayFabは多機能な分複雑な上、日本語の情報が少ないので、扱うのが少し難しいと思います。

なので初心者の方であれば、シンプルで日本語の情報が多い、NCMBをおすすめします。

NCMBについては↓の記事が分かりやすいです。

【Unity】NCMBを使ってサーバにデータを保存、取得する方法 | tama-lab

さて。

今回は、Unityで使用しているアセットを中心に今の僕の開発環境について書きました。

まだ今後、課金機能、ガチャ機能などを作る予定なのでその時に使ったものについてはまた後日書きたいと思います。

こちらからは以上でーす。ではでは。

大学生がゲームを作り始めて3ヶ月経過、残りやることを整理する

2019-06-06T21:06:07+09:00

2019/5/18

おはようございます。

1日1記事以上書いているブロガーさんは素直に凄いと思っている、大学生ゲーム制作者の村人Uです。

僕は1記事に3日かかります。

さて。

ゲーム制作がそろそろ折り返し地点になってきたので、ここら辺で少しタスクの整理をしようと思います。

開発開始から3ヶ月の時点で、こんな事考えてます。

残りのタスク一覧

技術

Twitterにプレイ動画を投稿する機能(無理なら画像)
もう一度遊ぶ機能(パーティー維持)
ランク機能
コイン機能
課金システム
ガチャ
カメラの制御
言語のローカライズシステム
あと2キャラ実装
ゲームシステムの変更

デザイン

スキルエフェクト
カメラエフェクト
スキル使用時の環境エフェクト
タイトル画面の一枚絵
メニュートップ画面のUI
フレンド画面のUI
キャラクター選択画面のUI
ゲーム画面のUI
ガチャの演出

音楽

タイトル画面のBGM
メニュー画面のBGM
ゲーム画面のBGM
UIタップ音
スキルのSE
リザルト画面のSE(可能ならBGMも)
マッチング完了時のSE

マーケティング

公式ツイッターの開設
事前登録キャンペーン
公式サイトの開設
宣伝、広告
キャラ購入とガチャ(おまけ)でマネタイズ
PVの制作

問題

メインのゲームシステムがただのデスマッチから何か面白そうなルールに変えたい！
初期ユーザーがどれくらいいるか分からない、0の可能性も0じゃない！
マルチプレイだから、人がいないとゲームが成り立たない！でもソロモードを作る余裕はない！
事前登録でキャンペーンにする内容が思いつかない！(初期ユーザーを増やすのが目的なので他のキャンペーンじゃなくても良い)
広告を出すお金がない！

さて、こんな感じです。

ゲームを遊ぶだけなら、ほぼ完成していてブラッシュアップや周辺機能を作っていく感じです。

とはいえ、どれも爆弾レベルの問題をたくさん抱えているので、気が気ではないですが、完成は8月と言い張っているのでやるしかありません。

特に宣伝は致命的にヤバいです。

どうやったらみんなに知ってもらう事が出来るのかなあ。。

今は素直に完成が楽しみです。

引き続き頑張ります。

こちらからは以上でーす。ではでは。

京大・名大・同志社大の連合チームでゲームを作る by 大学生ゲーム制作者

2019-06-03T23:25:19+09:00

2019/5/15

おはようございます。

このブログの投稿は僕しかやらないので、いい加減本名晒しても良いかなぁと考えている、大学生ゲーム制作者の村人Uです。

そういえば、僕らの作業の環境について触れた事がなかったので、今日は少しその話をしたいと思います。

3大学の連合軍

僕らは3人で開発を行っていますが、全員別の大学に通っています。

名古屋大学、京都大学、同志社大学です。

県をまたいでそこそこ遠いです。

なので実際に会って開発をするわけにはいきません。

どうしているかというと、僕らはDiscordという通話アプリを繋ぎながら夜な夜な開発を進めています。

大体一回の作業で3時間くらいですね。

そして、作業の最後には次回の予定と次回までの予定を決めるようにしています。

次にやる日をその時に決めて、次の作業日までに余裕があったらやるべき作業も共有しておく感じです。

これを決めておかないと、なあなあになってしまうので結構大事だと思います。

こんな感じでやることを共有

僕らの役割分担

僕らは3人チームなので、それぞれの役割を決めなくてはいけません。

と言ってもたった3人だから簡単で、

プログラマー 1人

デザイナー 1人

サウンドクリエイター 1人 です。

プログラマーとサウンドクリエイターは高校の頃からそれっぽい事をしていましたが、デザイナーは1ミリもそっち系の人では無かったのでめちゃくちゃ大変だと思います。

僕の周りには誰も絵を描ける人がいなかったので、0からデザイナーになってもらった感じです。

本当に頑張ってくれていて、毎回渡される絵のクオリティには驚いています。

めちゃめちゃ助かります。

間も無くもう一人、PV制作、公式サイト制作をしてくれる人を増やそうと思っています。

作業のようす

基本はリモートワーク

書いた通り、僕達は基本的に通話を繋いで開発を進めるのですが、役割がまるで違うので作業自体はそれぞれ別のことをしています。

なので大抵の場合、特に話をするわけでもなく静かにそれぞれの作業をしています。

俗に言う、もくもく会というやつです。

同じ作業をするわけでもないのに意味があるのかと言われると、人によるとしか言えません。

僕も昔は意味が無いと思っていて、それどころか一人の方が集中できるものだと思っていました。

というか、多分僕はそっちの人間です。

でもどうやらこの世界には、他の人と一緒に作業をしていた方が他の事に逃げずに集中できるという人もいるようで、その人にとってもくもく会は効果的です。

この辺りは僕の経験でもあります。

さて、僕達はこんな感じで開発しております。

一応、こんなでも3ヶ月は続いていて、ちゃんと完成も近づいてきています。

結構新しいスタイルかなと思うので、気になる人は参考にしてみてはいかがでしょうか。

物理的な制約はもう無くなりつつあるみたいです。

こちらからは以上でーす。

ではでは。

eスポーツとゲームの違い by 大学生ゲーム制作者

2019-06-02T01:21:20+09:00

2019/5/12

おはようございます。

記事に書く事が思いつかなくて、最近作業をサボっている事に気づいた、大学生ゲーム制作者の村人Uです。

意外なところでブログをやってる意味を感じました。

さて。

書く事が思いつかなかったので、10分くらい悩んで、最近マーケティングの話ばっかりだなぁと思い、ゲーム制作者らしくゲームの話をしてみようと思います。

今はメニュー画面を作り中・・・

eスポーツが現れた！

今、何かとチヤホヤされているeスポーツという言葉があります。

ご存知でしょうか。

eスポーツのeは「electric」つまり、電気のスポーツという意味です。

で、要するにただのゲームの事なのですが、これが最近は大会とか開いちゃって、その大会で生活するプロとか出てきちゃったりして、まるでスポーツじゃないか！という事で、eスポーツという名前が付いたようです。

そんなeスポーツですが、昔と今のゲームの変化をおさえていないと「ゲームとスポーツを一緒にするな」などと言い出すので、今日は今のゲームを正確に捉えてみようと思います。

昔と今ではゲームの目的が違う！

昔のゲームは、完全に娯楽でした。

ゲームをやる理由は楽しむ為で、それでご飯は食べられず、学業の成績が落ちたりしました。

子供は家にこもるようになり、それを見た母親は、ゲームは悪者だ！と言います。

(これが昔のゲームで、ゲーム＝怠惰のイメージの元です。)

昔のゲーム代表

しかし時が経つにつれ、ゲームは1人プレイだったのが複数人でプレイ出来るようになりました。

すると、ゲームを通して他の人に"勝つ事"に重点が置かれるようになります。

勝つ事に重点が置かれ始めたゲームは、多くの人が1番になりたいと思うようになりました。

そして、分かりやすく１番を決める手段として大会が開かれるようになります。

この大会が徐々に増え始め人の目にとまるようになって来た今、これがeスポーツという名前になり注目を集めています。

(なぜeスポーツという名前になったのかは今回は触れません)

今のゲーム代表

さて。

この話の中で何が変わったのかと言うと、ゲームが1人プレイから複数人プレイに変わったのです。

もっというと、ゲームの目的が与えられたクリアを目指す(1人で楽しむ) ところから、人よりも強くなる事に変わりました。

ゲームが1人用のオモチャから、人と競うコミュニケーションツールに変わったという事ですね。

前者が(昔の)ゲーム、後者がeスポーツになります。

この2つには、明確な違いがあるわけです。

あとは簡単で、スポーツの定義が「人と競うルールを決める」事であるならば、ゲームもその役割を果たしているので、eスポーツと言われているのだと思います。

(将棋や囲碁がスポーツと呼ばれていないので、スポーツの定義は少し違うのですが、およそで合っています)

日本のゲームの今

さて。

日本では、このオモチャとしての昔のゲームのイメージが異常に強く、ゲームのコミュニケーションツールとしての役割が知られていない為、eスポーツは流行っていません。

というか、昔のゲームしか知らなかったらeスポーツは理解が出来ないと思います。

ここまで、昔のゲームという言葉を使って来ましたが、オモチャとしてのゲームは昔に限った話ではありません。

未だに、1人プレイのゲームは増え続けていますし、その人気も衰えていません。

今は、オモチャのゲームとスポーツのゲームがごちゃごちゃになっている状態ですね。

別の目的で遊ぶにもかかわらず、全部ゲームという名前になってしまっているんです。

そこで間もなく、eスポーツという言葉はオモチャのゲームとスポーツのゲームを分ける意味でも使われ始めると思います。

時代はオモチャのゲームの時代から、スポーツのゲームの時代に移ろうとしています。

というか、日本以外の主要な国では既にかなりこれが進んでいます。

(日本でeスポーツが浸透しないのには理由があります。)

今日は、昔と今ではゲームをやる目的が違うよって話でした。

ゲーム関係の人や、親御さんは乗り遅れないようにした方が良いと思います。

ではでは。

ゲームの売り方を世界ベースで考えたら勇気をもらった by 大学生ゲーム制作者

2019-05-31T22:45:22+09:00

2019/5/7

おはようございます。

「力は継続なり」ではなく「継続は力なり」が生き残っているのは面白いなぁと感じている、大学生ゲーム制作者の村人Uです。

ゲームの完成が現実味を帯びてきて、いよいよマーケティングに不安を感じ始めた今日この頃。

そんな中、昨日こんな記事を見つけて少しやる気が出たので共有したいと思います。

https://appmarketinglabo.net/hypercasual-applovin/

書いてある内容はおよそ、

最近のスマホゲームの流行りは「ハードコア」と「ハイパーカジュアル」だよ
宣伝の仕方次第で、収益(インストール数)は数百倍変わるよ
初期費用は50万くらいで、上手くいくと数億稼げるよ
↑の2つは海外での受けが良いよ

って感じです。

それで。

今僕の作っているゲームが、2作あります。

もう分かると思うんですが、それが「ハイパーカジュアル」と「ハードコア」なんです。

ルートは違いますが色々考えて、僕もこの2つを作ろうと思い至っているので、それが既に結果に出ている人達がいるというだけでかなり勇気をもらえました。

いや、本当に経験がないもんですから不安でしょうがないんですよね。

さらに。

海外では、ドット絵の人気があるというでは無いですか。

しかも、日本人にとってウザい広告も海外ではそうでもないという。

僕らの作っているゲームはドット絵で出来ています。

言語対応の面倒くささから、海外で売る事はあんまり考えてなかったんですが、こんなの見たらやらずにはいられません。

という事で、僕らの作っているゲームは海外進出を狙います。

しかし。

ここで大きな問題が。

結果を見るために、最低50万くらいだよって言われました…。

どうやら、感覚が完全に企業のようです。

残念ながら、個人開発で大学生の僕らにそんなお金はありません。

なので。

僕たちは、1万円でどれだけの結果が出るかをやってみます。

全部で1万円です。

令和元年8月頃にリリースします。

どうなるか、結果が楽しみです。

今のビジネスの多くはネットが使われます。

そして、ネットの市場は簡単に世界に移ります。

もし日本での販売を考えているのなら、一度日本以外の国の人が欲しいんじゃないかと考えてみるのはアリだと思います。

ではでは。こちらからは以上でーす。

大学生ゲーム制作者は、へび、とり、うし、きつねを作り始める

2019-05-29T22:27:55+09:00

※2019/5/3の記事です。

平成から令和になる瞬間をネタにしようと思ったものの、普段通り過ぎてネタにすらならないと気づいた、大学生ゲーム制作者の村人Uです。

5月になりましたね。

僕にとっては令和よりも、5月になったという方が中々えぐい感覚があります。

と、いうのもゲーム制作の当初の予定では4月中にメニュー画面を完成、5月中にキャラクターを追加する予定でした。

そして、若干(かなり？)遅れているものの、まぁ動くメニュー画面が完成したので、ついにキャラ追加の期間に突入した事になります。

で、このキャラ追加が実は死ぬほど大変で、やらなきゃいけないのが、

キャラのスキルを考える
キャラのスキルを実装する
キャラのアニメーション絵を作る
キャラのアニメーションを実装する
メニュー画面でキャラを追加する
キャラのデバッグをする

というのをしなくてはいけません。

で、何が大変って、これを各キャラごとにやらなきゃいけません。

5月中には最低でもあと、へび、とり、うし、きつねの4体は作らないとまずい。

ということは、↑の作業を1週間に1キャラのペースでやらなきゃいけない。

って言う事です。

さて、このキャラ追加に関してちょっとした工夫をお伝えしようと思います。

面白いキャラを3体、面白そうなキャラを3体用意する

このゲーム『プレイ・ザ・フォックス』には十二支、つまり12体のキャラクターが登場します。

で、最初のリリース時にはキャラクターは6体のみの実装にするのですが、この6体をどの動物にするか決めなくてはなりません。

ここで今回重要に考えたのが、「面白そうな」 キャラクターを選ぶという事です。

あえて 「面白い」ではありません。

どう言う事かというと、プレイ・ザ・フォックスでは、いくつかのキャラクターはコインで買う事を考えています。

買うまではそのキャラクターはプレイ出来ません。

ここに、通常のキャラクターとの違いを感じました。

通常のキャラクター(始めからプレイ出来るキャラクター)は絶対にプレイするので、プレイした時に楽しいかどうかが問われます。

対して、課金キャラの場合プレイした時の面白さの前に、そのキャラを買うかを考える時間があります。

その時の決定に大きく影響するのが 「面白そうか」 だと思いました。

要は、そこに実際に面白いかどうかが介入する余地は無くて、キャラの紹介文や雰囲気で「面白そうか」がすべてになるという事です。

聞こえ方によっては 「プロモーション次第で中身は適当でも良い」 と受け取られてしまいそうなので、一応書いておくと、

実際その通りだとは思います。

が、それは短期的に見たときだけで長期的に見るとまずいと思います。

また、逆に言うとどれだけ 「面白い」キャラクターがいても「面白そう」じゃなかったらプレイすらしてもらえなくなってしまいます。

そんな悲しい事にはしたくないので、「面白そう」はやはり大事だと思います。

そういうわけで、「プレイ・ザ・フォックス」では初期キャラクターに 「面白い」キャラクターを3体、「面白そう」なキャラクターを3体用意してみました。

また、アプデで追加されるキャラクターも「面白そう」を重視すべきなので辰や猿は残してあります。

長期的に見ると、全部出すよりその方が良いと思います。

ものづくりの場面で 「面白い」はもちろん大切ですが、それは「面白そう」かも考えてみると良いかもしれません。

ではでは。

【PlayFab入門】UnityでPlayFabサーバーとデータの送受信

2019-05-28T19:37:44+09:00

2019/4/28

おはようございます。

「１日３食、夜は寝る」は誰が決めたんだろうと思っている、大学生ゲーム制作者の村人Uです。

今回は、Azureが運営するPlayFabというサービスを利用して、サーバーでデータ管理をする方法について書きます。

説明はUnityを使用したものになりますが、使い方はUnity以外でもあまり変わりません。

PlayFabについては、別の記事に書きましたので今回は実際の使い方について触れていきます。

無料で使えるmBaaSのPlayFabをプレイヤーデータ管理に使ってみた by 大学生ゲーム制作者 - QUEST LAB

サーバーにログインする

PlayFabでは、ユーザーがサーバーに必ずログインする必要があります。

といっても、ユーザーにIDとパスワードを決めてもらう必要はなく、こちらで勝手に決めたIDでログインができます。

//using PlayFab.ClientModels;をスクリプトの最初に記述して下さい

public static void LoginPlayFab(Action resultCallback = null)
    {
        var request = new LoginWithCustomIDRequest { CustomId = SystemInfo.deviceUniqueIdentifier, CreateAccount = true};
        PlayFabClientAPI.LoginWithCustomID(request, result => OnLoginSuccess(result, resultCallback), OnLoginFailure);
    }

上記の例で、LoginPlayFab関数を使う事でPlayFabにログインする事ができます。

なかなかヘンテコな書き方があって、見慣れないかもしれませんがPlayFabを使う場合は今後もこんな感じで書いていきます。

        var request = new LoginWithCustomIDRequest { CustomId = SystemInfo.deviceUniqueIdentifier, CreateAccount = true};

この部分では、ログインするためのリクエスト文を作成しています。

この中のCustomIdがユーザーを識別するIDで、ユーザー毎にユニークな（唯一の）IDを指定する必要があります。

今回の場合は、SystemInfo.deviceUniqueIdentifier という端末ごとに違うIDを取得して利用しています。

このように、CustomIdやCreateAccountのようなPlayFabさんが事前に決めた変数名に値を代入する事でPlayFabのサーバーにどんな指示を送るか決める事が出来ます。

注）これらは、using PlayFab.ClientModels; がスクリプトの最初に記述されている必要があります。

サーバーにデータを送信する

サーバーへのログインに成功したら、データを送信する事が出来るようになります。

public static void SendUserData(){
   PlayFabClientAPI.UpdateUserData(
            new UpdateUserDataRequest(){
            Data = new Dictionary() {
            {"Coin", "10"}
        }}, result => Debug.Log("Successfully updated user data"),
            error => {
                Debug.Log("Got error setting user data");
                Debug.Log(error.GenerateErrorReport());
            });    
}

これまたヘンテコなのですが、↑ではPlayFabClientAPI.UpdateUserDataという一つの関数しか使っていません。

このように関数を使う事によって、今回の場合サーバーに、「キーが"Coin"、値が"10"」のデータを送信する事が出来ます。

ちなみに、この関数は↓のような引数を取っています。

PlayFabClientAPI.UpdateUserData(UpdateUserDataRequest request , Action resultCallback, Action errorCallback);

今回の場合、この中のrequestの部分が

new UpdateUserDataRequest(){
            Data = new Dictionary() {
            {"Coin", "10"}
        }}

に当たり、resultCallbackが

 result => Debug.Log("Successfully updated user data")

に当たり、errorCallbackが

error => {
                Debug.Log("Got error setting user data");
                Debug.Log(error.GenerateErrorReport());
            }

に当たります。

サーバーからデータを受け取る

サーバーへの送信とほぼ同じ感覚で出来ます。

public static void GetUserData(){
 PlayFabClientAPI.GetUserData(
            new GetUserDataRequest() {
            PlayFabId = PlayerData.Instance.MyPlayFabID,
            Keys = null
        }, OnGetUserData
        }, (error) => {
            Debug.Log("Got error retrieving user data:");
            Debug.Log(error.GenerateErrorReport());
        });
}

public static void OnGetUserData(GetUserDataResult result){
         if (result.Data == null || !result.Data.ContainsKey("Coin")) Debug.Log("No Coin");
        else result => Debug.Log(result.Data["Coin"].Value);
}

↑の例では、PlayFabサーバーからユーザーデータを取得し「Coin」というキーを持つデータの値を取り出しています。

ここでもサーバーにデータを送信する時と似た感じで、次のような関数を使っています。

PlayFabClientAPI.GetUserData(GetUserDataRequest request , Action resultCallback, Action errorCallback

送信時と大きく違うのは、この関数の引数の内resultCallbackに当たる部分がOnGetUserDataになっているという事です。

見てもらえれば分かるように、resultCallbackの型は Action になっています。

この Action という型は、「GetUserDataResultを引数にとる関数」を表します。

なので、今回の場合OnGetUserDataというGetUserDataResultを引数に持つ関数を指定する事が出来ます。

そしてこのresultCallbackという引数ですが、これはPlayFabからデータの取得が成功した時に呼び出される関数になります。

つまり、今回の場合データの取得が完了したらOnGetUserDataという関数が呼び出されることになります。

またその時に引数に渡されるGetUserDataResultに様々な情報が格納されています。

実際には、上記のようにresult.DataにデータがDictionaryの形で格納されているのでそれを利用する事が多いと思います。

もっと知りたい

今回書いたのは、正確にはPlayFabの中のごく一部の機能であるPlayerDataについてです。

PlayFabにはデータの管理の方法だけでも

Player Data
Read Only Data
Internal Data
Group Data
Shared Group Data

など、様々なデータの扱い方があります。

複雑に感じるかもしれませんが、逆に言うとそれだけ機能が充実しているという事でもあると思います。

詳しい説明は↓のPlayFabのドキュメントに載っています。

現時点(2019/4/28)で全て英語ですが、グーグル翻訳を使えば割と読めちゃいます。

最近のグーグル翻訳は凄いですね。

Azure PlayFab のドキュメント - PlayFab | Microsoft Learn

自分で作ったオンラインゲームを4人で遊んでみた by 大学生ゲーム制作者

2019-05-27T21:49:46+09:00

2019/4/25

おはようございます。

期限が2日後に迫った２０ページのレポートに追われている、大学生ゲーム制作者の村人Uです。

一昨日、2ヶ月間2人で作り続けてきたゲームをついに身内にお披露目しました。

僕らの作っているゲーム「Play The Fox」は今だと最大4人で遊べるようになっております。

しかし、開発陣はたったの2人でしてテストプレイすらまともに出来なかったわけです。

そこで、開発者2人含め、ちょうど友達4人集まる機会があったのでそこでお披露目をしました。

で、お披露目をした感想なのですが、めっちゃ楽しかった！

正直、作りの甘さからまともに楽しめないんじゃないかと思っていましたが、全然クッソ楽しかったです。

ただ同時に、バグだったり詰めの甘さだったりの今まで見えていなかったものもたくさん浮き彫りになりまして、自分の思っていた進み具合よりもこれは随分遅れてしまったいるなぁと感じました。

そんなこんなで、集まってくれた友達は何と仲間になりまして、1人はゲームのBGM•SE制作を、もう1人はゲームのPV制作をやってくれるみたいです。

ある程度完成したら、誰かに見せるというのは想像以上に大事かもしれません。

大事な事が何か見えてきますし、モチベーションが上がります。

さて、ここまで来たら絶対に失敗するわけにはいきません。

これからは今まで以上に頑張ります。

とにかく、今は今後が楽しみです！！

こちらからは以上でーす。

マネタイズから見たスマホゲームのガチャの立ち位置 by 大学生ゲーム制作者

2019-05-26T22:30:45+09:00

2019/4/22

おはようございます。

人類は睡眠に時間を使い過ぎだと感じている、大学生ゲーム制作者の村人Uです。

今日はスマホゲームのマネタイズ、主にガチャについて書きます。

一般的には…

スマホゲームのマネタイズの手法は様々あります。

まず、スマホゲームの収入源は

アプリ自体の購入料金
アプリ内課金
広告
の3つがあります。

アプリ自体に価格をもたせる場合、無料ゲームに比べインストール数が伸びない為、一人で遊べるゲームが多い傾向にあります。

対して、アプリ内課金を利用する場合、

スタミナの回復
魔法石の購入
ガチャ

などで採算を取ります。

広告の場合は、

広告料金
広告を非表示にするために課金

のどちらかになります。

主流は…

現在、いわゆるスマホゲーで成り立っている会社の多くはガチャで採算を取っています。

日本には昔からガチャガチャがあります。

しかし、ガチャガチャがそこまで採算がとれるほど熱狂的なものだったかというと怪しい所があります。

これだけガチャが流行っていれば、現実世界でガチャガチャが増えても良さそうなものですが、

ガチャが流行っているのはゲームの中だけで、現実世界からはむしろ消えつつあります。

では、現実のガチャとゲームのガチャは何が違うのか。

そもそも、ガチャの本質は運100%のギャンブルと変わりません。

日本でギャンブルといえば、パチンコやスロットです。

ここで注目すべきなのは、ガチャは消えてもパチンコやスロットは未だに熱狂的な人気があるという事です。

では、ここの違いは何か。

この違いは、リターンの大きさにあります。

ガチャで出るのがおもちゃであるのに対して、パチンコで帰ってくるのはお金です。

それも、場合によっては何倍にもなる可能性を秘めています。

ここでゲームのガチャに戻ります。

ゲームのガチャで得られる物はゲーム内のキャラやアイテムです。

そして、このキャラやアイテムの中には超レアで強いものが入っていて、これが大きなリターンの役割を担っています。

ギャンブルでは大きなリターンとしてお金を採用しますが、ゲームではキャラを採用出来るという事です。

つまり、ゲームのガチャは現実世界のガチャの皮を被ったギャンブルが近くて、本質的にはパチンコやスロットと変わりません。

自作のゲームに活かすには…

逆に、ここから見えてくる事が1つ。

それは、大きなリターンを用意できなければガチャは失敗するという事です。

たくさんお

ただのおもちゃが出てくるだけのガチャは、現実世界のガチャよろしく、熱狂的な人気は望めません。

その為、今のゲームは異常にキャラのバランスが悪く、圧倒的に強いキャラとたくさんの超雑魚キャラがいるわけですね。

しかし個人制作のゲームの場合、この超雑魚キャラを"たくさん"作るのは厳しかったりします。

また、圧倒的に強いキャラというのはガチャとしては良くてもゲームとしては作りたくない場合があります。

例えば、オンライン対戦ゲームで人対人の場合、課金者が強くなってしまうようではただの札束の殴り合いで無課金者は楽しくないです。

企業は利益を目的としているので、これでも決行する場合がありますが、大して利益を求めていない個人制作者の場合は面白さを重視して避けたいと考える場合は多いです。

つまり、個人制作者がガチャを成功するためには、

たくさんの超雑魚キャラの代わりを用意する
ゲームを壊さない程度の超ハイリターンを用意するかその代わりを用意する

僕たちの場合、1については例えばTipsとかキャラの色違いとかボイスとかで対応すれば良い。

しかし、2についてはどうしてもゲーム崩壊を招く上、顕著にレアだと分かるものが思いついていない。

今後、2に対して良い回答が出来ない場合はガチャの実装を見直した方が良いかもしれない。

これは、ゲームだけに言えることではなくてマネタイズの手法の一つとしてギャンブルを取り入れてみるのも良いのではないかと思います。

こちらからは以上でーす。

エンタメ分野の”面白い”とは何か by 大学生ゲーム制作者

2019-05-25T10:18:12+09:00

2019/4/19

おはようございます。

めちゃ急げば間に合う時間に起きてしまい、絶起よりも絶起した大学生ゲーム制作者の村人Uです。

最近ゲーム制作の手が止まっており、予定よりやや遅れ気味になっちゃってます。

というのもここ数日は ゲームの面白さの本質は”お客さん” にあるという意識を持ち直しまして、

そこ基準にした時にこのゲームクソ面白くねぇなとなって、ゲームシステムをアホみたいに変更したのが原因です。

さて。

今日は最重要とも言える、ゲームに限らずエンタメ全般に言える "面白い"とは何か を書きます。

当然のことですが、サービスが面白いかどうかを決めるのはお客さんです。

そこには僕たちの介入出来るスペースは1ミリもありません。

なので、お客さんにとって面白い事は何か考える事が全てになります。

多くの人がここに辿り着きます。

しかしここで、ごく自然に出て来てしまう答えが

「結局、自分が面白いものを作る事が、皆にとっても面白いものが出来るよね。」

です。

この考えは絶対にやめてください。

今すぐに捨ててください。

そんな物は思考を放棄したご都合主義に他なりません。

完全に自分が楽しむ事第一で楽な方に逃げています。

年齢、性別、職業、収入、家庭...

アナタとお客さんは全く違います。

もし、エンタメで生きていきたいなら絶対に無視することは出来ません。

自分の楽しいもの、身内で盛り上がるだけの「身内ノリ」は他人にとってはクソ寒いだけです。

そこまで考えると、次に僕たちのやるべき事が見えてきます。

まず、僕らに必要なのはこの「身内ノリ」を止める事です。

ではどうするか。

「身内ノリ」が発生する原因の1つは、そもそも「身内ノリ」だと気付いていない事です。

これを解決するには、お客さんの”求めている”事を徹底的に想像するしかありません。

中高生は友達とワイワイしたい。

20代社会人はストレス発散がしたい。

40代子持ちの人は、子供と遊べるものが欲しい。

こういった事をひたすらに想像します。誰かと議論するのも良いです。

ここの精度によってプロダクトの良し悪しが決まります。

場合によっては、そもそも「面白い」を求められていない可能性すらあります。

そして、もう一つ。

身内ノリを指摘する人の存在が必要です。

開発メンバー全員がそれを出来るのが望ましいです。

「でもそれって身内ノリじゃない？」

「それは僕らが楽しんでるだけじゃない？」

「お客さんは求めてないよ」

これを言えるかどうかで、出来上がるものが大きく変わってきます。

厳しいかもですが、これがなくては完成した後に絶対に後悔します。

...ここまで偉そうなことをつらつらと書いてきましたが、これは僕の失敗経験から来ています。

実際のところ、まだこの考えを使ったプロダクトをリリースしたことはなく、これが本当に正しいかどうかはこれから実証することになります。

しかしながら１つも間違ったことを言っているつもりもなく、正しいかどうかは今後の僕らを見てれば分かると思います。

とにかく言いたいのは、

「折角興味を持ってくれたお客さんを全力で喜ばせてあげようよ」 ってことでした。

こちらからは以上でーす。

大学生スマホゲーム制作者がお金をかけないマーケティングを考える

2019-05-24T00:24:00+09:00

おはようございます。

外食では選ぶ時間がもったいなくて、メニューの左上か左の人と同じものを注文する大学生ゲーム制作者の村人Uです。

最近は、ゲームのマーケティングというか集客みたいな事ばかり考えていて、それが決まらないと先に進めないので大変です。

僕らの作っているスマホゲーム「Play The Fox」は複数人で遊ぶオンラインゲームなのですが、そもそも人がいないと遊ぶことが出来ません。

という事で、プレイをする"人"を集めなくてはいけないわけですが、当然そんな事をやった経験はないのでなかなか苦労しております。（コードが書きたい！）

マーケティングの王道

まずは、一般的なスマホゲームのマーケティングを書いておきます。

一口にマーケティングと言っても種類があるわけですが、ここでは初期プレイヤーの獲得を目的にしたマーケティングに関して考えます。

広告
Twitter
YouTube
TV CM
ウェブサイト

１番多いのはTwitterです。

Twitterは拡散力がずば抜けている為、いわゆるバズを起こしやすいです。

基本的な使い方としては、事前登録のキャンペーンを実施したり情報解禁をしたりします。

例えば、3000リツイートでアイテムがもらえるとか、プレゼントキャンペーンみたいなことをします。

次が、広告です。

Twitter、YouTube、ウェブサイト、アプリ内などありますが、人の目に付く場所に広告を載せる事で世間に認知させることが出来ます。

YouTubeなどもありますが、多くの場合この２つが大きいと思われます。

個人開発者のマーケティングの限界

個人開発者が上記の方法をそのまま使おうとすると問題が起きます。

それは、元手となるお金と名前が無いという事です。

Twitterの場合、事前登録をしてもらうにはリツイートをしてもらう必要があります。

そしてTwitterで伝えられる情報はめちゃくちゃ少ないです。

その中で事前登録をしてもらうには、リツイートしたくなるような面白そうな動画、企画などを行う必要が出てきます。

この時、既に実績のあるゲーム会社であれば前作からの期待で事前登録する人が一定層います。

対して個人の場合そのような人はおらず、最初のリツイート者が出ずに終わってしまうパターンがありえます。

また、予算の差と人手の差から企業ほどの企画も出来ないでしょう。

広告に関してはさらに無理があります。

広告を出すにはお金がかかります。

これは割と馬鹿にならないくらいかかるので、お金に余裕があるか、回収できる相当の自信作でないと厳しくなります。

僕が仕掛けたい策「Line」

まだ詰め切れていないのですが、今考えている策があります。

それがLine連携です。

ゲーム内からLineで招待を送る機能を作ります。

本来、Lineはそこまで拡散力は高くないですが今回はあえてLineを使おうと思います。

そもそも、僕ら個人開発者が作ったゲームがストレスなく他のプレイヤーとマッチング出来るほどの人を集める事はほぼ不可能です。（相当Twitterでバズった場合はあり得ます）

結果、「面白そうだけど人がいないからつまらない（プレイできない）」現象が発生してこのゲームは一生報われません。

それではお客さんにもゲームにも申し訳ないので、せめてインストールしてくれた人だけは良い思いをさせてあげたいです。

ではどうするか。

そもそも、ゲームをプレイするだけならプレイできる最小人数さえ集まれば良いはずです。

その人数は大抵の場合、「身内」だけで事足ります。

そして今、身内に声をかける最強のツールが「Line」です。

Lineで連絡が来たら皆見ますよね。

ただし、Lineの懸念点は「誘いづらい」と「面倒くさい」です。

Twitterなどの不特定多数に向けての発信と違って、Lineの場合相手の顔が分かっています。

その人と一緒にゲームをする事への抵抗だったり、申し訳なさから連絡しづらい可能性があります。

また、Lineの場合、

ゲーム内からログイン→誘う相手を選択→送信ボタンを押す

の３ステップが必要になり単純に面倒くさいので、避ける可能性があります。

ひとこと

一般的なマーケティングについてはあまり詳しく触れられなかったので、また別の記事にまとめようかと思います。

個人制作者がどうしてもマルチプレイのゲームに手を出しづらい現状をどうにかしたいです。

ひとまず、僕らの「Play The Fox」は「身内で遊べる最強のゲーム」を目指してみようと思います。

こちらからは以上でーす。

スマホゲームを協力対戦にする利点と欠点 by 大学生ゲーム制作者

2019-05-22T19:51:09+09:00

2019/4/13

おはようございます。

英語が話せる国に生まれただけで、多すぎるアドバンテージを得られる世界をどうにかならないかと思っている、大学生ゲーム制作者の村人Uです。

今日の電車の中で1記事チャレンジです。

さて、僕らの作っているゲーム「Play The Fox」ですが、これは2vs2を可能にするスマホゲームです。

実は始めの頃は1vs1の対戦ゲームだっのですが、ある理由から2vs2にする事にしました。

その理由が、結構単純で、人気のあるスマホゲームが協力対戦型が多いから。なんです。

ここでいう、人気のあるゲームは荒野行動やモンスト、白猫プロジェクトのような物を指します。

人気ゲームに協力対戦が多いという事は、それらのゲームを受け入れる人達が多いという事になります。

Play The Fox でも、まずは先人から学べという事でこのシステムを取り入れようと考えたわけです。

しかし、先人の敷いたレールの上を歩くだけではいつまでたっても先人の背中しか見えません。

間も無く、僕らはこのレールを外れていこうと思うのですが、それがあさっての方向に向かわないようにはしなきゃいけません。

さて、少し話が脱線しましたが、この理論でいくと2vs2どころか4vs4でも良い事になります。

当然その通りで、4vs4も作るか非常に悩んでいます。

しかし、一つ懸念しなくてはいけない事があります。

それは、僕らは企業と違って名前とお金が無いという事です。

何が言いたいかというと、初動で人を集めることが出来ないんです。

オンラインの対戦ゲームをするには、マッチング出来る人数プレイする人がいないといけません。

プレイする人が多ければ多いほど、マッチングにかかる時間は減り、ゲームの質を高めます。

そして、人を集める常套手段は広告です。

しかし広告を出すにはお金がかかります。

元手のある企業ならそれが出来ますが僕らには出来ません。

1vs1なら、最低2人。

2vs2なら、最低4人。

4vs4なら、最低8人。

さらに全てのモードを実装した場合、各モードに人が分散するのでより多くの人数が必要になります。

下手をすれば、マッチングしなくてそもそもゲームで遊べないなんて事になりかねません。

結論を言うと、ゲームを多人数にすると言うことは、

プレイする上では面白くなるものの、

そもそもプレイする人がいなければ遊ぶ事すら出来なくなるリスクを負うと言うことです。

この辺りのジレンマと戦わなくてはなりません。

対策としては、モードを絞る、コンピュータを用意する、マッチング待機時間を楽しくする、などありますがまだ明確な答えは出ていません。

面白い回答を用意出来るようもっともっと考えようと思います。

こちらからは以上でーす。

【近況報告】大学が始まりました。 by 大学生ゲーム制作者

2019-05-21T22:37:54+09:00

2019/4/12

おはようございます。

いつまでもGoogleの天下はつまらないなぁと感じている、大学生ゲーム制作者の村人Uです。

今朝は7時過ぎに母親の声で起きまして、7時30分に家を出ました。

この時間ならギリ間に合います。母親は偉大です。

この記事は大学行きの電車の中で、唐突に大学行くまでに1記事チャレンジをしたものの６割くらいしか書けず結局今書き上げたものです。

このチャレンジ難しい。

さらっと記事を書いてしまう人は凄いですね。

背景が残念すぎるトップ画面

さて、2月から始まったゲーム制作ですが、今はメニュー画面を作っております。

これがなかなかに大変で、フレンド申請の機能を作るために1週間使いました。

1週間は早いと感じるかもしれませんが、メニューには.、

トップ画面、キャラクター選択画面、フレンド申請画面、ガチャ画面の4つ

があって僕はこれを1ヶ月でやらなきゃいけないので1機能1週間では間に合わないわけです。

(画像でかすぎ問題)

にも関わらず。なんと大学の授業が始まりました。

昨日なんか、3〜5限が同じ授業で長いなーと思っていたら20時までかかる始末。

(大学の5限終了時刻は本来18:00)

しかも、課題レポート２０ページだと。

この授業を考えた人は、脅されていたか、酔っ払っていたとしか思えません。

兎にも角にも、時間がありません。

ここから先は馬車馬です。

寝てる暇などない。

今後の予定的には、

４月　メニュー完成

５月　キャラクター増量

６月　見た目ブラッシュアップ

７月　リリース

となっています。

現状ですが、メニュー画面が半分くらい出来てきました。

絶対無理だろうと思っていたフレンド機能も、完成の兆しが見えています。

デバッグの段階で軽く機能しているのを見て感動しております。

やってみるものですね。

絵は全然ありませんが、まぁそれは６月にがっつり。

さて、どうなることやら。

今後は完全にメニュー画面作成に手をかけるので若干地味になります。

そろそろ宣伝とか、マネタイズとか考え始めないと。

えっ、シューカツ？

なんか、急に電波が悪くなったみたい。

こちらからは以上でーす。