前回の記事でplayerキャラを作成したので今回は敵キャラを作っていきます。

敵キャラとしてMask Dudeを採用するのでAssets/Pixel Adventure 1/Assets/Main Characters/Mask DudeよりIdleをすべて選択してHierarchyへドラッグアンドドロップします。

保存場所を聞かれるのでCharactersへ保存します、名前はEnemyAnimationとでもしておきます。

サイズが小さくなってると思うのでplayerと同じようにplayer per unitのサイズを32へ変更します。

ついでにHierarchyのEnemyのアニメーションの名前をIdle(32×32)からEnemyにでも変えておきます。

敵キャラは複数配置することを考えてプレハブ化していきます。
まずAssetsの下にprefabフォルダを作成します。

先ほど作ったEnemyに関してprefabへドラッグアンドドロップ

今後はPrefab内のEnemyの設定をいじっていくためHierarchyのEnemyを消去します。

敵キャラに当たり判定と移動を付け加えていきます。Prefab内のEnemyを選択してOpen Prefabをクリック。

当たり判定を付けるためにAdd ComponentからCircle Collider 2Dを選択して追加。そうすると円の当たり判定が追加されます。

今のままだと当たり判定がデカすぎるのでOffsetを編集して判定を少し小さくします。こんな感じ。

同じ手順Add ComponetでRigidbody 2Dを追加して物理演算の付与。ConstraintsのFreeze Rotation Zにチェックを入れて回転しないようにします。

終わったらPrefabからScene画面へドラッグアンドドロップでEnemyの追加を行います。

動かすとこんな感じ。

敵キャラの準備ができたので移動させるためにスクリプト書いていきます。

Playerの時と同じようにAssets/Scripts内にScriptを作成、名前はEnemyManagementにでもしておきます。
ScriptについてはPlayerのScriptから入力部分を削ったものを以下のように記述。

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class EnemyManagement : MonoBehaviour
{
    public LayerMask StageLayer;

    // 動作状態を定義する 
    private enum MOVE_TYPE
    {
        STOP,
        RIGHT,
        LEFT,
    }
    MOVE_TYPE move = MOVE_TYPE.LEFT; // 初期状態は左に移動 
    Rigidbody2D rbody2D;             // Rigidbody2Dを定義
    float speed;                     // 移動速度を格納する変数

    private void Start()
    {
        // Rigidbody2Dのコンポーネントを取得
        rbody2D = GetComponent<Rigidbody2D>();
    }

    // 物理演算(rigidbody)はFixedUpdateで処理する
    private void FixedUpdate()
    {
        // Playerの方向を決めるためにスケールの取り出し
        Vector3 scale = transform.localScale;
        if (move == MOVE_TYPE.STOP)
        {
            speed = 0;
        }
        else if (move == MOVE_TYPE.RIGHT)
        {
            scale.x = 1; // 右向き
            speed = 3;
        }
        else if (move == MOVE_TYPE.LEFT)
        {
            scale.x = -1; // 左向き
            speed = -3;
        }
        transform.localScale = scale; // scaleを代入
        // rigidbody2Dのvelocity(速度)へ取得したspeedを入れる。y方向は動かないのでそのままにする
        rbody2D.velocity = new Vector2(speed, rbody2D.velocity.y);
    }
}

Scriptを書き終わったらprefabフォルダ内のEnemyを選択してopen prefabを選択。そこで先ほどのEnemyManagementをEnemyへドラッグアンドドロップします。

反映されているのを確認したら再生。こんな感じになるはず。

敵キャラの実装と移動が可能になりました。
次回は敵キャラの落下回避や当たり判定作っていきます。

はじめに

この記事は単なるポエムです
現在進行形でUnityを使っている人に有益な情報は一切ありません
もし、昔Unityを触っていた人が偶然この記事を見て、
「ここが原因でUnity使うの辞めたんだよな」と言う人がいたとしたら、
今のUnityはとてもよくなっているので、もう一度触ってもらえると嬉しいです

なんでこの記事を書いたか

ちょうど私がUnityを使い始めて、2021年で10年になります
なので、この10年でUnityがどう変わっていったかを振り返ろうかと思いました
しかし振り返っていると、「今思うとあれは酷かったな…」と思うものがいくつか出てきたので、
せっかくなのでネガティブになってしまいますが、愚痴という形で過去のUnityを振り返ろうかと考えました

・UIのデフォルトのシステムが悪い

今でこそuGUIがあり、Hierarchy上でUIを配置して確認ができるようになっていますが、
uGUIが出る前はOnGUI()でUIを配置するのがデフォルトでのUIシステムでした
OnGUI自体は今でもあり、Editor拡張で使っている人も多いと思います
（残念ながらEditor拡張ではまだ現役です）
このOnGUIだけで愚痴が1記事余裕で書けるほどのものでした。主だったものを上げると
・実行しないと配置が確認できない
・Buttonを１つ使うたびDrawCallが増える
・そもそも関数が書いてある時点でボトルネック

などがありました。では当時どう開発していたかと言うと、AssetStoreでNGUIと言うアセットを買っていました
それはもうみんな買っていました。定価90$したと思いますが、開発には必須だったのです
あまりにもみんな購入していたのが理由なのか、NGUIの作者は後にUnityに入社してuGUIを手掛けます

・日本語に対応していない

日本語対応していない。と聞くと、Editorのメニューやドキュメントが対応していない。と思う人も多いでしょう
もちろん今はそれらも日本語対応しています
しかし、ここで言いたいのは「日本語入力」の問題です
当時、UnityではEditor内で日本語の入力ができませんでした。なので一回メモ帳などで書いたものをコピペしていました
Editor内だけではなく、当時のUnityのデフォルトの開発環境であったMonoDevelopも日本語入力に対応していませんでした
（後に日本語入力もできてユニティちゃんも眺められる、痛MonoDevelopと言う物も流行りました）
じゃあMonoDevelopではなく、VisualStudioを使えば良い。と思うでしょう。実際使いました
そこでも日本語で問題がありました
日本語でコメントを打つと、その次の行までコメントアウト扱いになってしまうのです
じゃあ英語で全部コメントつけるのか？　となりますが、解決策は
// 日本語のコメント打てるよ! .
と最後に半角文字をいれると防げました。

・日本語での情報がほぼ無い

今はUnityの日本語の情報はいっぱい出てきます。公式のドキュメントも日本語対応されている物も多いです
コミュニティも多くできていて、本も大量に出版されています
しかし当時は本やコミュニティも日本にはほぼ無く、ブログで技術記事を書いてあるところも少なかったです
Unityの方々もそれは理解していたのか、FacebookでUnityユーザー助け合い所と言うものを作ったり、
そこで公式の方々が親切に質問に答えていたりしていました

・2Dゲームが作りづらい

当時、UnityはUnity3Dと言う名称でした。そう3Dなのです。2D用には作られていませんでした
前述した通り、Unityは2DのデフォルトUIが大変使いづらい物でしたので、
3Dのシステムを使ってなんとか2Dゲームを作っていた。と言う時代でした
ただそうなると、当たり判定や重力処理は3D用の物なので、2Dにはあまり使えません
なので全部自前実装になっていました

・謎の言語UnityScript

UnityはC#のイメージが強いのですが、当時はJavaScriptが多かったです
自分が知る限り最初に出た日本語のUnity本もJavaScriptで書かれていました
問題は、UnityのJavaScriptはJavaScriptと言う名前ですが、言語仕様が違っていたのです
(むしろActionScriptに近いのでは無いかと言われていました)
なので、JavaScriptが出来る人がUnityを触って困惑した。と言う話をいくつか聞いていました

それといまだに謎なのですが、JavaScriptではUpdate()内でyield;が使えていました
毎フレーム呼ばれる物になんで使えていたんだろうか…

・コンパイルやビルドが劇遅

当時、モバイルゲームをUnityで作っていたりもしたのですが、
この時は作りやスペックの問題もあると思いますが、１行変更したら、その変更をコンパイルするのに３分ほどかかっていました
もしそこでtypoなどあれば、また修正して３分待つ必要があります。地獄でした
そこで、少しでも早くするため、作業途中のスクリプトはPluginsフォルダで作業する。と言うハックがありました
UnityのコンパイルはPluginsフォルダが先に行われるため、そこでコンパイルエラーは防ごうと言う魂胆です
また、ビルドもとても時間がかかりました。当時はCI/CDの知識も技術もあまり無く、愚直にビルドして実行していました
Androidはまだ良いのですが、特にiOSへのビルドはXCodeも通す必要があり、40分以上はかかっていたと思います

・バージョン管理システムAssetServer

当時、UnityはUnity内で完結出来る、AssetServerと言うシステムを売り出していました
Gitのような物ですね。ただこちらが曲者でした
基本的にはコミットして、他の人はそれを持ってきて、競合が発生したら破棄するかマージするかを選択する
と言うような、基本的なバージョン管理システムです
ただ、AssetServerはブランチを切れません（無理やりコピー作ってブランチ作るなどはできます）
コミットがプッシュ扱いなので、ローカルの作業を一旦コミットしてログに残す。と言ったこともできません。
その上、マージするときも差分を確認しながらなどがやりにくく、多人数で開発すると、コンフリクトからのマージ失敗で作業内容が消えると言うことが多発しました
結局当時はGitに乗り換えました。このAssetServer、1ユーザーで400$ぐらいしたと思います

・AssetBundleがとにかく使いづらい

AssetBundleは今でも使われる物ですが、当時はAssetBundleでググると
「AssetBundleは何がクソなのか」と言う記事が最初にヒットしていました
（今見たら消えてました）
挑戦的なタイトルですが、内容は完全に同意出来る物だったと記憶しています
個人的に一番の問題だと思っていたのは、当時のAssetBundleはUnityのバージョンが上がると、
AssetBundleの互換性がよく切れていて、AssetBundleのビルドどころかユーザーにデータのDLをさせ直していました
また、EditorでAssetBundleのシミュレートモードがなかったので、AssetBundleをビルドしてサーバに上げて、実機でDLして確認…
と言う面倒な作業をしていました。前述の通り、当時はCI/CDが整備されていなかったので手作業です

AssetBundleは何がクソなのか。に最後に書かれていた文が印象的なのですが、
「一番クソなのはこのシステムを使わなくてはいけないことだ」
みたいな事が書いてあって、同意すると共に笑った記憶があります

最後に

ここまで愚痴を書いてきましたが、これらは全て過去の話です
いかにUnityが進化し、使いやすいものになっていったかを認識できました

また、色々と愚痴を書いていますが、「じゃあなんでUnity使ってたの？」と思うことでしょう
当時は、ゲームエンジンはとても高価なものでした。特に3Dが使え、マルチプラットフォーム対応
それをUnityは数十万円払えば、Proライセンスを買い切りで使えたのです
（当時は買い切りでUnityPro,iOSPro,AndroidProがありました）

また、何よりもUnity Technologies Japanの方々が改善や布教に尽力していたのが好感持てて、印象的だったと言うのもあります
積極的にコミュニティやイベントを開催し、質問事項のメールの返信も迅速で丁寧でした。これは今でもですね

これからのUnityの進化にも期待しています

マルチプラットフォームなUnity案件では、プラットフォームを切り替えるときの待ち時間とても長いです。
プロジェクトの規模が大きくなると、切り替える度に1時間以上待たされたりします。

この対策として、プラットフォーム別にプロジェクトフォルダを用意する作戦があります。
(もちろんリポジトリは共通で)
これが最も効率のいい方法ではあるのですが、編集先ミスって度々事故るんだこれ。

というわけで…

下準備

一旦Unityを閉じて、Libraryフォルダをコピーします。
これで察したら、あなたとても鋭い。

Windows用としてサフィクス付けました。

iOSに切り替えてみます。

一旦Unityを閉じて、LibraryフォルダのコピーをiOS用としました。

今度はAndroidに。

これ以上切り替える必要なくなったら、リネームでOK.

切り替え方法

編集対象のプラットフォームに対応するLibrary_*から
シンボリックリンクかジャンクションでLibraryを作る。
切り替えたいときは、一旦Unityを閉じてから作り直すだけ。