マガジンのカバー画像

Unityメモまとめ

21
ゲーム実装の記録と、調べた内容のまとめ
運営しているクリエイター

記事一覧

BGMやSEを鳴らす(Unityメモ)

いわゆるサウンドシステムの話 必要な機能(要件)ゲームにはBGMやSE(効果音)がつきものです。BGMで作品の雰囲気やシナリオ内の感情を言葉によらず伝えられます。またSEがあると操作の意味を伝えたり、操作に楽しさを付け足すことができます。これらBGMやSEを操作するのがいわゆるサウンドシステムです。 必須機能 ・マルチチャネル再生できるようにする ・BGM ・UI用SE(決定、キャンセルなど) ・戦闘用SE(打撃、エフェクトなど) (・キ

マップを作る(2)(Unityメモ)

クラス構造の見直し。 シーン間の情報伝達ゲーム内のイベント演出では、「マップから戦闘シーンに移行」「ホームに戻る」というような、シーン間の遷移を行うものがあります。特に戦闘シーンへの遷移では、敵パーティやマップ固有のパラメータといった戦闘情報をマップシーンから戦闘シーンへ伝達する必要があります。前回の記事ではその部分が未設計でした。 クラス構造の見直しシーン間遷移を設計するにあたって、前回の設計のままシーン間の情報伝達を組むと処理が煩雑になったので、実行フローとクラス構造

マップを作る(1)(Unityメモ)

設計内容を一部修正しました。シーン遷移については続編の方を参照してください。 シーン・マップ・演出に関する基本的な考え方は同じなので、以前の記事はそのまま残しておきます。 今までの作業の応用編。動作はこんな感じ マップシーンの扱い戦闘要素があるゲームでは、プレイヤーが移動するシーンもだいたい存在します。その名前はマップ、ステージ、フィールドなど様々ですが、ここでは移動範囲の単位となる要素をマップと呼びます。 アクション、シューティング、シミュレーションなど多くのゲームで

マスタデータを作る(3)(Unityメモ)

遅れた夏休みの宿題を片付ける気分 用語についてドメイン駆動設計の特徴として、ドメインの用語を使ってソフトウェアの設計を行う点があります。 そのためドメイン駆動設計に沿ってゲームを設計する際も、同様にゲームの用語を使ってクラス名などを定義することになります。ただしゲームの場合は一般的な業務システムとは異なり、そのゲーム固有のルールや世界観に沿った概念を用いることがよくあります。そのためゲームシステムの設計では、ゲーム固有の概念を一般的な概念と対応付けることが難しい場合があり、

マスタデータを作る(2)(Unityメモ)

記事を分割しました。 前回の記事はこちらです。マスタデータを配置する前提となる、プロジェクトのフォルダ構成についてです。 データのインポートAddressablesを使うと、マスタデータを用途ごとにサブフォルダに分割しつつ、アセットを一括ロードできます。しかしその場合でも、アセットファイルを1枚ずつ用意して各フォルダに置く手間はそのままです。コンテンツを少量ずつ追加する分にはいいのですが、開発中にまとめて配置したい場合は手作業が多すぎます。そこでCSVファイルなどを使ってデ

マスタデータを作る(1)(Unityメモ)

Unityのエディタ拡張に手を出した マスタデータとシステム本体を分けるマスタデータはシステムを実際に使う上で必要なデータを指します。ゲームの場合、ユニットの能力値やマップ情報、キャラ画像などを指します。 マスタデータはユーザデータと違ってユーザの使用中に変更することはありません。それでも大抵の場合、マスタデータはシステムの外部に別建てで用意します。システムの実装部分に直書きするとアップデート時に変更しづらいのと、マスタデータをシステム本体と分けておいた方が分業しやすいため

システム構成を整理する(2)(Unityメモ)

システム設計は責任分担の調整、つまり政治 前回のまとめ・ユースケースの記述方法やクラス関係を再検討したい ・モジュールを整理するため、ヤードという概念を導入。機能の保守責任の分掌、つまり所属に近い概念。名前空間による実装が意味的に近い ・モジュール間の依存性の整理をする方法が必要だと気づいた 今回も車輪の再発明を進めてゆきます。 依存性の整理インタフェースの所属を下位側に割り当てる システム設計において、モジュールの依存性を整理することが大事です。特に相互依存があると

システム構成を整理する(1)(Unityメモ)

再発明した車輪を整理するのに1ヶ月かかってしまった 現状の実装ウィンドウ表示前の処理 メニュー構造の中で、スロットに対する操作の実行時に開くウィンドウを指定できるようにしました。また操作実行時の処理に非同期処理を指定できるようにしました。 操作実行時の処理は以前からあり、これはウィンドウがOnEnableする前に実行されます。ユニット一覧ウィンドウを開く前にウィンドウのコンポーネントにユニットデータを与える、といった処理ができます。 //操作とスロットの定義public

データをセーブする(3)(Unityメモ)

前回からの続き。やっとC#とUnityの出番 セーブデータの暗号化セーブデータのセキュリティ 情報セキュリティの要素の記事を再掲します。 これを参考に、セーブデータ処理についてもセキュリティの要素を考えてみました。 ・機密性:暗号化したセーブデータを解読・不正に復号されない。 →秘密鍵を秘匿する ・非改ざん性:改ざんされていない。 →改ざん検出により不正な暗号文を受理しない ・真正性:なりすましを受け付けない。 →秘密鍵による署名をつける。システム

データをセーブする(2)(Unityメモ)

通信とセーブデータとでは暗号化の前提条件が違っていた なぜ暗号化したいのか前回の記事でも書きましたが改めて。 制作中のゲームについて、特に他人と関わる要素をつける予定は現状ありません。一人遊びが一人で閉じている分には、チートをしても自己満足で閉じるだけです。それでもセーブデータの暗号化について考えているのは、技術的な興味という趣味の領域です。逆にゲームが他人に何らかの関わりを持つのなら、社会からチート対策が要求されることになります。 またチート対策は運営からの対策がメインに

データをセーブする(1)(Unityメモ)

大枠を作った セーブデータの扱い方必要な機能 ある程度の規模のゲームを続けるうえで必要となるのが、ゲームを終了しても途中から再開できる機能です。その際に必要なのがゲームの進捗のセーブとロードの機能です。 実装したい機能の要件は以下の通りです。 ・ゲーム進捗(所持ユニットなど)のセーブ・ロード ・セーブデータの改ざん対策 ・容量を小さく抑える 性能の要件は以下の通りになります。 ・100件単位の規模のデータをセーブ・ロード ・容量の上限はスマホ環境のストレージに収まる程度

メニューを作る(4)・トラックパッド風GUIを作る(Unityメモ)

使い勝手はトラックパッドというよりトラックポイント 動機「メニューを作る」シリーズの最初にも触れていますが、ゲームのGUIでスマホの横向き片手持ちでも使いやすいものを組もうとしました。 スマホの片手持ちだと親指だけでGUIを操作することになります。親指の操作だけでメニュー選択と決定が出来そうなGUIとして、トラックパッド風の入力GUIを実装してみることにしました。 制作中のゲームGUIでは、スロット(ユースケースの引数、メニュー項目)とスロットがもつ操作(「ユニット」スロ

アイコンを作る

作ってみたものの。 UIとアイコン ゲームに限らず、現在の道具には何かしらのアイコンや絵がついていて、道具の使い方や機能のヒントをユーザに示しています。 制作中のゲームでも、メニューや操作のアイコンを表示することにしました。 作ってみたキャラ絵をStable Diffusionに「発注」したように、私には絵を描く能力はありません。なのでアイコンのデザインもStable Diffusionで作りました。 当初はアイコンを切り抜いて完成品にしようと思ったのですが、最終的にはS

メニューを作る(3)・ウィンドウ表示(Unityメモ)

操作の実装のあたりをつけます。 操作の呼び出し実装中のGUIでは、ユースケース(シーン)→スロット(ユースケースの引数)→スロットごとの操作とたどっていき、操作を指定してGoを押下すると操作用のウィンドウが開きます。パーティ編成などデータの操作は個々の操作ウィンドウの中に実装する、という方針です。Unityの場合はデータ操作などの動作をコンポーネントに分けて実装できるので、機能追加も比較的行いやすいです。 メニューからウィンドウを開く メニューのデータ構造にはボタン選択