enumを使わない怪異（実装した感想）

たのしい２Dゲームの作り方 第二版

横スクロールの簡単なアクションゲームが学べます
さぞかしコードもシンプルかと思いきや・・・

たのしい２Dゲームの作り方 第二版　という本がkindleでセールだったので３Dは作るの大変すぎたので２Dに絞ろうと考えて試しに買ってみました。

買った理由はXでフォローしている方がこの本を実際に使って横スクロールゲーム作っててその出来が良いなと思ったからです。

実際、横スクロールアクションゲームのシンプル見本としてはゲーム仕様はとてもよくできていて、複雑過ぎず、これぐらいのボリューム感はちょうどいいなと思いました。

ただ、この本、Amazonレビューにも書こうと思いますがソースコードがイケてないです。ここまでシンプル路線なのでコードもさぞかしシンプルだろうと期待したら、まさかのstring書きまくりのstateをstringで管理するというBASIC言語でももう少しマシな実装方法あるよ？という驚きのコードでした。

// アニメーション対応
Animator animator; // アニメーター
public string stopAnime = "PlayerStop";
public string moveAnime = "PlayerMove";
public string jumpAnime = "PlayerJump";
public string goalAnime = "PlayerGoal";
public string deadAnime = "PlayerOver";
string nowAnime = "";
string oldAnime = "";

STUDIO SHIN. 
たのしい2Dゲームの作り方 第2版 Unityではじめるゲーム開発入門 (pp.252-253). 
株式会社翔泳社. Kindle 版. より引用

こういうコードで実装すると問題がたくさん出ます。第一に、打ち間違いが起きやすくなります。第二に修正時に修正漏れが起きやすくなります。第三にこのコードを初見で手本として覚えた人はenum（列挙型）という便利で安全なコードの実装方法を知らないまま旅立ちます。

実際、このstring多用コードは教本の説明をややこしくするのにも効果を発揮していて「enum使わないとこうも中途半端に複雑なコードになるんだなー」と驚くほど汚いコード書かされるので途中で嫌になってロジック理解した後は教本無視で実装コードを書いてしまいました。本買った意味！

ちなみにenum使うと下記のように直感的なコードになります。
コード補完機能が効くのでStringで直書きと違いTYPOも発生しなくなります。nowAnimeとかoldAnimeは本当にやめたほうがいいと思う。

    public enum AnimationState { PlayerStop, PlayerMove, PlayerJump, PlayerGoal, PlayerDead }

    public enum PlayerState { Playing, Goal, GameOver, Stop }
    public static PlayerState GameState { get; set; } = PlayerState.Playing;

ピクセル合わせしてないのでズレやすい

この教本にはもう一つ問題があって、２Dゲームのピクセルを等倍で作るという手法が実践されていません。そのため、教本通りに実装するとゲームクリア時にキャラクターが位置ズレなどを起こすロジックなのですがそれを直すコードも綺麗に書けません。ピクセルがバラバラに用意されているからです。

もしかすると、こうした課題を散りばめることで読者の成長を促すという著者の大胆な仕掛けなのかもしれませんが、自分の場合は不具合にしか思えず、大雑把に作らされれて問題が次々露見するので気持ち悪いから片っ端からコード作り直しながら作るという羽目になりました。

卵かけご飯を作るのに親子丼の作り方はいらない。。。

作っていて思ったのは、サンプルの見た目と裏腹にバックエンドの複雑な仕様です。どうしてこんなに絡まった糸のような作り方で教えるのだろう？なんでこんなメンテナンス性最悪のコードでわざわざ教えるのだろう？という疑問とストレス、そして、簡単なものを複雑にすることへの素朴な疑問です。

サンプルそのものは卵かけご飯なみの簡単なものです。それが親子丼でも作るかのような複雑な手順で実装方法を教えていきます。本のページ数稼ぎ？いやまさかそんなことはないだろうと思うのですが、どうしてこういう教え方なんだろうと理解が進むほど疑問ばかりが広がります。

２Ｄ横スクロールは見本通りのものができましたがコードの9割を書き直して、放置されているバグもいくつか直して実装しました。これで勉強するのはしんどいなあ・・・でも買っちゃったし勿体ないから続き作ろうか・・・と思いながら本を眺めています。

いいところもあるのですが、プロパティ化を教えてないので、この本だけで学ぶとＣ＃の優位性を全く生かさないゲームしか作れない人になるなあと思いました。

仕事でもC#（WPF）で業務用コードを書いているので余計に思うのですが、この教本通りに書くとsonar（VSCodeに拡張機能でつけれる綺麗なコードを書くためのナビゲーション機能）がすっごいうるさく警告出しまくるんですよ。そりゃそうだよ、私だってこんなコード書いたことないもの。意図して適当に書こうと思ってももう少しコンパクトにしか書かないし書けないので、悪魔的ともいえる複雑さにビックリしてその驚きを日記に残すことにしました。

Unityのエディタの使い方は分かりやすい

酷評していますがUnityエディタは癖が強いので、Unityエディタが私のようにまだ全然慣れてない人間には順を追って画像スプライト処理を丁寧に教えてくれる点は良かったです。願わくば、そのいいところを台無しにするようなコードじゃなければ最高でした。お手本コードが100歩譲っても妥協できないぐらい酷いコードなのでコードは書けるけどUnityエディタの使い方が分からないという人にはちょうどいいのではないでしょうか。多分。

ただまあ、C#の綺麗な書き方学び終えた人には、苦行になる一冊かなと思います。教本コードを読んで「バグが起きやすいコードの書き方」の見本市場だなと思いました。自分がゼロベースで書くなら絶対にそうは書かかんよという箇所が多すぎます。何でもPublicにしてみたりfloatの比較演算子が不安になる書き方だったり。

Unityを勉強していると、不思議なコード（普通にプログラム勉強していたらセオリーとしてありえないような書き方の危険なコード）を沢山目にしますが、こうした本が原因なのかもしれません。私はそうした危険な実装例が引っかかってしまってコード書く時間は一瞬で終わるのですが、遅々として学習が進まない敗因になってるので、いい加減、気にせず前に進みたいのではあるのですが。

GPTにロジック相談しつつエディタの使い方は教本で学ぶが着地かなあと最近ぼんやり思いながら、作った２Dゲームのサンプル動かして思いました。20年以上前に散々作った２Dゲーム、UnityになるとUnityで楽できるところは楽できるんだけどUnityそのものの設計ミスみたいな仕様にハマる。いい加減、その負のループを卒業したいのだけど、まだ時間かかりそうです。

まあ、誰かが待ってる訳でもないのでのんびり気長に進めるとしましょう。